Systems and methods for providing personalized delivery services

ABSTRACT

Systems and methods are disclosed for providing personalized delivery services by a carrier providing a package delivery service. For example, a consignee may indicate a delivery preference to be applied to delivery of a package, such as indicating a specific location where the package is to be left upon delivery, if the consignee is not present to accept the package. In one embodiment, the consignee may be notified by the carrier of the scheduled delivery of the package, and may be linked to the carrier&#39;s web site to indicate a delivery preference. Alternatively, the delivery preference may be indicated by the consignee proactively accessing the web site. After conveying a delivery preference, the carrier&#39;s systems communicate the delivery preference at the appropriate time to a portable computing device which informs the delivery personnel of the consignee&#39;s delivery preference. Other embodiments allow the consignor to indicate delivery preferences.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. application Ser. No.12/616,183, filed on Nov. 11, 2009, which is a continuation of U.S.application Ser. No. 11/460,268, filed on Jul. 27, 2006, which is acontinuation of U.S. application Ser. No. 11/425,333, filed Jun. 20,2006, which claims priority to U.S. Application No. 60/750,684, filed onDec. 14, 2005, U.S. Application No. 60/701,712, filed Jul. 22, 2005, andU.S. Application No. 60/692,849, filed Jun. 21, 2005, the contents ofwhich are hereby incorporated in their entirety by reference.

BACKGROUND

The package delivery business typically involves three main entities inthe course of delivering a package: a carrier, a consignor, and aconsignee. The carrier typically arranges the delivery of a packagebetween the consignor and the consignee, and is often referred to as apackage delivery provider, service provider, or common carrier. Theconsignor is the entity that causes the package to shipped, and can bereferred to as the shipper or originator. The intended recipient of thepackage is the consignee. In the case of a package being shipped as partof a mail-order or Internet-based purchase, typically the consignor isthe merchant and the consignee is the customer of the merchant.

The process of delivering a package is well known. Typically, theconsignor prepares the item to be shipped, selects a carrier and classof service (e.g., normal or expedited delivery), and arranges for thecarrier to gain custody of the package. This may occur by the consignorbringing the package to a carrier's pickup location or arranging thecarrier to pick up the package at the consignor's premises. Once thecarrier takes possession, the carrier routes the package to a handlingfacility in the town or serving area of the consignee. The package isthen delivered to the consignee, usually using a delivery vehicle.

Typically, the carrier maintains a regular route for the delivery ofpackages, and along the route will stop at the appropriate consignee'saddress and attempt to deliver the package. In an optimal deliveryexperience, the carrier delivers the package on the initial attempt tothe consignee, who is present to accept the package.

However, as can be expected, in many instances the delivery experienceis not optimal in that the package is not successfully delivered on theinitial attempt. There are a number of reasons why this may occur. Acommon reason is that the consignee is not present, and therefore unableto receive and sign for the package. In some circumstances, this may notbe a problem because the delivery location is determined to be secureand/or the class of service associated with the delivery may not requirea signature. For example, a class of service may not require aconsignee's signature for delivery or a secure lockbox may be providedfor deposit of the package. However, in many instances, the class ofservice (or other constraints) requires a recipient to be present toaccept and sign for delivery. This results in the consignee and thecarrier entering into various procedures to coordinate a follow-updelivery attempt.

For a delivery provider, such as UPS, handling millions of deliverieseach day, each failed delivery attempt requires additional time andresources for coordinating a follow-up delivery attempt. Not only doesthis result in decreased efficiency for the carrier, but it results inan undesirable delivery experience for the consignee, and potentiallythe consignor as the package is not delivered as soon as it could be.

Thus, in order to affect an optimal delivery experience, coordination isrequired between the consignor, carrier, and consignee. All the partieshave an interest in achieving prompt delivery.

However, in many instances, delays may occur, schedules may change, orthere may not be complete knowledge by all three parties of the detailsof the delivery. For example, a consignor may be delayed in providingthe package for shipment, thus resulting in delaying the anticipateddate of delivery to the consignee. Alternatively, the consignee may notbe able to accept delivery because he is not present. For example, theconsignee may have stepped away from the delivery location for a brieftime period, or may be away on vacation. Often, the consignee worksduring normal delivery hours and cannot be present at a residentialaddress to accept delivery. Or the consignee may plan to be present, butdue to a schedule change, cannot be present.

In other instances, the delivery may occur, but in less than optimalcircumstances. For example, delivery of the package may be accomplished,but the placement of the package at the consignee's delivery locationmay not be as the consignee desired. For example, the consignee maydesire the carrier to deliver the package to a side entrance instead ofa front entrance so as to avoid theft. Or, the consignee may regularlyuse the side entrance rather the front entrance. The consignee may havedesire to have the package placed in a secure lockbox, but has notcommunicated a combination to the carrier for unlocking the lockbox.

Thus, systems and methods are needed to allow for greater coordinationbetween the consignor, the carrier, and the consignee of a package so asto achieve a successful and optimal delivery experience without wastingresources and incurring unnecessary delays in the package deliveryprocess.

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWING(S)

Having thus described the invention in general terms, reference will nowbe made to the accompanying drawings, which are not necessarily drawn toscale, and wherein:

FIG. 1 is a high level diagram of a consignee services system inaccordance with one embodiment of the present invention.

FIG. 2 is a flow chart illustrating a method of providing consigneeservices, in accordance with one embodiment of the present invention.

FIG. 3 is a diagram illustrating further details of components of aconsignee services system, in accordance with one embodiment of thepresent invention.

FIG. 4 is a high level diagram of a customized pickup and deliverysystem in communication with delivery personnel, in accordance with oneembodiment of the present invention.

FIGS. 5 a and 5 b illustrate a method of providing various consigneeservices according to various embodiments of the present invention.

FIG. 6 illustrates an exemplary delivery authorization form according toan embodiment of the present invention.

FIG. 7 is a diagram illustrating one embodiment of the architecture of acarrier's information processing system for providing personalizeddelivery services.

FIGS. 8-11, 12A-12B, and 13-27 illustrate a map of a web site, andexemplary screenshots thereof representing various embodiments of thepresent invention.

FIG. 28 illustrates an exemplary process of receiving an electronicsignature from a consignee on an electronic delivery authorization form,and enabling consignors and carriers to access the signed form.

DETAILED DESCRIPTION

The present inventions now will be described more fully hereinafter withreference to the accompanying drawings, in which some, but not allembodiments of the inventions are shown. Indeed, these inventions may beembodied in many different forms and should not be construed as limitedto the embodiments set forth herein; rather, these embodiments areprovided so that this disclosure will satisfy applicable legalrequirements. Like numbers refer to like elements throughout.

Service Overview

There are three main entities involved in the delivery of a package: theconsignor, the carrier, and the consignee. In order to provide variouspersonalized delivery services that may arise in conjunction with thedelivery of a package, methods and systems are defined for coordinatingand personalizing the delivery experience between these three entities.The flexibility of the various means of communication between theseentities, as well as the variety of information that can be conveyed,allows the carrier to accommodate various unforeseen circumstances thatmay occur in conjunction with the delivery of a package. Thecommunication and coordination associated with the personalization ofthe delivery service may occur either at the request of the consignee orthe consignor.

Although the embodiments disclosed herein are disclosed in the contextof the delivery of a package, the principles of the present inventionmay apply to delivery of other items, including freight, provision ofservices by dispatching service personnel, or any other type ofapplication involving delivery or dispatching. Thus, as used herein, theterm “package” is not limited to a parcel, but means any type of good orservice being delivered or dispatched by a carrier or service provider.

At a high level, the customization or the personalization of thedelivery experience may require or involve the coordination between the:

(1) carrier and the consignee,

(2) consignor and the carrier, and

(3) consignor and the consignee.

It can be readily appreciated why coordination between each of theseentities may be required. In the first scenario, the consignee may notbe present to accept delivery. Communication between the carrier and theconsignee may facilitate delivery by the entities agreeing on a timeand/or place to accomplish delivery. In the second scenario, theconsignor may request the carrier to alter the delivery address for thepackage. And, in the third scenario, the consignor and the consignee mayagree between themselves to modify aspects affecting delivery of thepackage and inform the carrier of the change (which then may involve thefirst or second scenarios). Thus, in many instances, communication inone of the aforementioned scenarios (e.g., between the consignor and theconsignee) may be followed by another instance of coordination (e.g.,involving the consignor and the carrier). For example, a consignee maynotify the consignor of a change of address after the consignor hasalready shipped the package, but before delivery has been accomplished.The consignor may then communicate the new address to the carrier.

As it will be seen, the first two instances of coordination involve thecarrier in some form and impact how or when the carrier accomplishesdelivery of the package. In many cases, the impacts to the carrier arehighly dependent on the particular facts surrounding the packagedelivery. For example, a consignor contracting for the delivery of apackage may require a signature by the consignee, and only theconsignee. This may preclude a request by the consignee to deliver thepackage to a neighbor instead. Of course, if the consignee communicateswith the consignor, the consignor may in turn authorize the carrier todeliver the package without a signature of the recipient, effectivelywaiving the signature requirement. Because various communications andcombinations of coordination are possible, only some examples areprovided to illustrate various embodiments of the invention.

Communication Between the Carrier and the Consignee

At a high level, the communication between the carrier and the consigneetypically involves the exchange of information to coordinate, orpersonalize, the package's delivery. Typically, although not required,the consignee is aware of an impending package delivery. This may occurvia several ways. In one common embodiment, the carrier may notify theconsignee of an impending delivery. This can occur via an emailnotification, although other forms are possible, including other formsof electronic messaging (e.g., short message service, automated voicetelephone calls, facsimile messages, hosted web site messaging, instantmessaging, etc.). In other embodiments, the consignor may notify theconsignee that a package has been shipped. This is quite common insituations in which the consignor is a merchant from whom the consigneehas ordered an item and the consignor provides notification when thepackage has actually been handed off to the carrier. Typically, theconsignor will also provide the consignee with a tracking number of thedelivery. In other embodiments, the consignee may be expecting a packagebased on other facts (e.g., the consignee ordered merchandise and wasexpecting delivery). In this case, the consignee may proactively accessa package tracking web site operated by the carrier to ascertain thestatus of the package delivery.

Typically, once the consignee is aware of an impending delivery, theconsignee can initiate a request for personalizing the delivery of thepackage. The consignee may communicate the request in different ways,including electronic messaging, such as via email or web-site access,via telephone, or other forms. The request typically providesinformation to the carrier that the delivery personnel use in thedelivery of the package. Such information may include identification ofthe package (e.g., via a tracking number), requests regarding when thepackage should be delivered on the day of delivery, where it should beplaced at the delivery address, or other special handling information.

Although personalized delivery information is often provided after theconsignee is aware of the existence of a package that will be delivered,this information can be also provided earlier. Specifically, a consigneecould indicate delivery preferences or instructions prior to a packagebeing shipped to the consignee. For example, personalized deliveryinformation can be provided by the consignee as standing instructions orpreferences for delivery of a package. Thus, the delivery preference isto be applied to all future deliveries, even if there is currently nopackage scheduled for delivery to the consignee. In other embodiments,the delivery information may be provided after the initial deliveryattempt. While the carrier may prefer to receive such information priorto an initial delivery attempt, embodiments of the present inventioncontemplate indication of delivery preferences by a consignee beforeand/or after an initial delivery attempt.

Communication Between the Consignor and the Carrier

Similarly, a consignor can provide personalized delivery information tothe carrier. In some embodiments, the indication of such information maybe made by the consignor contemporaneously with the indication of otherrelated package delivery information. A typical circumstance is acustomer ordering information from a merchant using web-access, and whenplacing the order the customer (which typically is the consignee)requests that the items be placed at a certain location upon delivery(e.g., the back door). Upon shipping the package, the merchant mayindicate to the carrier the destination address with specialinstructions regarding the delivery, including placement at the backdoor. This information could be included with other shipping informationprovided by the consignor to the carrier via a shipping system. Suchshipping systems allow a consignor to prepare packages for shipping.

In another embodiment, the customer may notify the merchant of thespecial delivery instructions, after the package has been shipped. Inthat case, the consignor (the merchant) may communicate the specialdelivery instructions to the carrier by referencing the package or theconsignee. Alternatively, and as discussed above, the consignee couldindicate such directly to the carrier after learning of the impendingdelivery.

In other embodiments, the consignor-provided personalized deliveryinformation could originate from the consignor itself, rather than fromthe consignee. For example, the consignee may know that it is shippinggoods which could be damaged if wet, and thus provide deliveryinstructions indicating that if the package is left at the consignee'sdelivery address without the consignee being present, the package is tobe wrapped or covered in plastic. As another example, the consignor mayrequire that all consignees provide “live” or in-person signatures forrelease of a package, and would provide this information as a standingdelivery preference to the carrier.

Communication Between the Consignor and the Consignee

The communication between the consignor and the consignee, by itself,does not involve the carrier and does not directly impact the deliveryof the package. However, a typical result of this communication is thatthe consignor or consignee will then communicate personalized deliveryinformation to the carrier regarding the package delivery. It ispossible that one party may expect the other to contact the carrier, ormay facilitate the communication so as to ensure the communication is asseamless as possible. For example, a consignor may communicate with aconsignee and learn that the consignee will not be able to receive thepackage. The consignor may provide the consignee with a web-address ofthe carrier and the tracking number of the package as well asinstructions of how to inform the carrier of this situation. Thus, theconsignor facilitates the consignee in indicating his personalizeddelivery information to the carrier. Alternatively, the consignor couldinform the carrier of the situation directly, after which the carriercan contact the consignee and inform him that his delivery preferenceshave been communicated. The consignor may have obtained the emailaddress of the consignee (such as at the time the consignee placed theorder with the consignor), and may provide this to the carrier forpurposes of allowing the carrier to communicate shipping statusinformation to the consignee.

Delivery Authorization Forms (DAFs)

The ability for the consignor or consignee to request personalizedpackage delivery creates a greater likelihood that the package will bedelivered successfully and in accordance with the consignee'spreferences on the initial delivery attempt. By most standards, deliveryof a package on the initial attempt is preferable as it results in thepackage being delivered sooner to the consignee, and it conserves thecarrier's resources. As discussed, delivery on the initial attempt doesnot always occur for various reasons. For example, a consignee may notbe available to receive the package, and will only know of the attempteddelivery after the failed delivery attempt. In these situations, manyservice providers, such as UPS, will leave an indication, such as apaper note, in a conspicuous manner at the delivery location indicatingthat a delivery attempt has been made. One such paper based form is theInfoNotice® used by UPS to indicate a delivery attempt. The consignee,upon arriving at the delivery location typically sees the deliveryindication and then is aware of the failed delivery attempt.

One embodiment of the present invention discloses providing theconsignee with a notification of the impending delivery prior to thefirst delivery attempt and provides, or enables the consignee to access,an electronic delivery authorization form (DAF). Generally, the DAF is aform that can be provided electronically to the consignee (e.g., viaemail) from the consignor or the carrier, or can be accessedelectronically by the consignee, such as via the carrier's website. Onepurpose of the DAF is to provide authorization of the carrier to leavethe package without the consignee being present to receive the package.The consignee can then print the form, sign it, and post it at thedelivery location in advance of the first delivery attempt. This allowsthe consignee to receive the package on the first delivery attemptwithout having to be present.

Another purpose of the DAF is to indicate delivery preferences and/ordelivery instructions for delivery of the package. The DAF may includevarious fields relating to delivery of the package, and allows theconsignee to indicate specific delivery preferences on the form (such asindicating that the package should be left at the back door). The DAFcan be generated by the carrier or consignor so as to have some of thesefields completed prior to the DAF being provided to the consignee. Inother embodiments, the consignee can fill in the fields on his own.

After printing a hard copy and posting it in a conspicuous place at thedelivery location, the delivery personnel retrieves the DAF upondelivery the package and associates the DAF with the package ordelivery. Typically, the DAF includes machine readable indicia thatallow delivery personnel to associate the DAF with the shipment of thepackage via a portable computing device carried by the deliverypersonnel at the time of delivery. In some embodiments, a DAF with anassigned identifier number may have already been logically associatedwith the delivery at the time that the DAF was provided to theconsignee. Specifically, the carrier may have associated the DAF withthe consignee's package at the time the carrier sent the DAF to theconsignee. Various other embodiments of the DAF are discussed below.

Structure of an Exemplary Consignee Services System

FIG. 1 is a high level block diagram of a consignee services system(CSS) 104 in accordance with one embodiment of the present invention.The CSS 104 typically includes a computing system 122 that may be aminicomputer, mainframe, server, or other computing device known in thearts. The computing system 122 typically includes a processor 124,associated memory 126, and an input/output controller 128. The computingsystem 122 may also comprise disk storage for storing one or moredatabases, such as the Consignee Profile Database 134 (shown in FIG. 1as being located remotely from the computing system, although in variousembodiments it may be stored locally to the computing system 122). Otherembodiments may use other forms of data storages (e.g., data stores), ormay use external databases that are accessed using a communicationnetwork.

The CSS 104 can send and receive email using an email interface 112 andmay host a web site, which is accessible via a web interface 114.Alternatively, a separate computer (not shown) may host the web site andcommunicate with the computing system 122. The CSS 104 can also comprisea telephonic interface 115 providing interactive voice response (IVR)capabilities to callers. The telephonic interface 116 can allowconnection to a customer service representative 120 that uses a computer118 that is able to communicate with the computing system 122. The CSS104 is also able to communicate with a consignee's computer 100 via theInternet, as well as a with a consignee 108 using the telephone network110 via the IVR, using well known methods of prompting the user forinformation that is entered using keypad depressions (e.g., touchtones). Thus, it is possible for a user to receive a notification via atelephone call providing an audio message, and indicating a deliverypreference by responding via touch-tone entry. In some instances, theuse of an IVR may not be as friendly or flexible as a web-basedinterface, but it may provide greater availability to those consigneesnot having ready Internet access via a computer. The system can alsocommunicate with the consignee via other methods known in the art. It isalso possible for the CSS 104 to communicate with the consignee orconsignor using an application program interface (API) 150, whichtypically would occur via the Internet 102, WAN, etc.

In various embodiments, the CSS 104 communicates using a local areanetwork (LAN) 106, or other network, to other systems 130 operated bythe carrier. In one embodiment, one of these other systems 130 is apackage level detail (PLD) database 133. The PLD database 133 maymaintain information about a package being delivered, including itsstatus, as well as other package related information. One embodiment ofa PLD database 133 is QuantumView®, which is a system operated by UPSthat stores and provides consignees' individual package levelinformation. In other embodiments, the PLD database may be separate ordistinct from the QuantumView® system.

As indicated, the consignee typically communicates with or accesses theCSS 104 using a computer 100 connected to the Internet 102, as is wellknown. Although not shown, other ways of accessing the CSS 104 arepossible, such as by using wireless access devices. As is known, cellphones, PDAs, and mobile computers can be used to send and receive emailmessages and access the Internet. Although these are not shown, theseforms of consignee access are possible as well.

The consignor's system 152 may employ several individual computingsystems, such as a main consignor computer 140 that interacts with anemail interface or system 142 for sending and receiving email messages.In many e-commerce applications, the consignor may send an email messageto the consignee when the consignee's order has been shipped, the emailmessage providing a tracking number as well. The consignor computer 140may interface or otherwise communicate with a shipping system 144. Thesesystems are also well known in the art, and aid in preparing a packagefor shipment. The shipping system 144 may collect the informationassociated with the package and package delivery, including theconsignee's address, and communicate the information to the carrier'ssystem 104, which the carrier then stores in the PLD database 130.Finally, the consignor system 152 can include a web interface 146 whichcan be used by the consignee to check on the status of the order, via aconsignor's web site for example. The consignor computer 140 can alsointeract with the carrier's system 104 via an API 147 or may simplydirect the consignee to a link on the carrier's website. Similarly, theCSS 104 may communicate with a consignor 140 via the consignor's webinterface 146, via an API 150 in the carrier's system, or via an API inthe consignor's system 147. In other embodiments, the CSS 104 maycommunicate with a separate carrier-operated shipping system (notshown), which in turn, communicates with the consignor's shipping system144. Although not shown, the consignor system 152 may also include atelephonic interface for allowing a consignee to communicate with theconsignor, and vice versa, via telephone.

Specific Consignee Capabilities

In various embodiments of the invention, a consignee can indicate andpersonalize delivery preferences for the delivery of a shipment. As usedthroughout, a “package” may be a container, parcel, or other such item.Delivery of a “package” thus encompasses a shipment of one or more ofsuch items. Therefore, in many instances, a shipment of more than onepackage is described and there may be delivery preferences associatedwith different packages within the shipment. Various options andcombinations of delivery preferences and instructions are encompassed bythe scope of embodiments of the present invention, and the followingprovides a high level overview of potential embodiments, but is notintended to be exhaustive. FIG. 8 illustrates an exemplary site map of acarrier's web site that provides consignees with the ability topersonalize the delivery experience. As can be seen in FIG. 8, and aswill be better understood from the description below, the carrier may beUPS and may have an initial web page 800 to allow a user to log in tothe UPS Personalized Delivery web site. A user can then be directed to aseries of web pages which allow the user to register, by inputting userinformation 802, alerts/release 804, delivery instructions 806, andwhich confirm the user's registration information 808. If the user hasalready registered, the user may be directed to a series of web pagesfor updating the user's preferences 810. The user may be directed to aseries of web pages to indicate a delivery change request 820. Variouscarrier customer web pages may be accessible to the user, as is known inthe art, such as a web page allowing a user to send a message to thecarrier 830 (such as a message indicating a problem with the web site orwith the UPS Personalized Delivery service), or to a web page havingFrequently Asked Questions (FAQs) 840.

Consignee Registration

In accordance with one embodiment of the present invention, a user canregister with the consignee services system 104 for purposes ofindicating standing delivery preferences and instructions. Thiscollection of consignee information is called a consignee profile. Theuser does not necessarily have to be a pending consignee (i.e., there isno package currently being processed by the carrier for delivery to thatuser). Nevertheless, the user is viewed as a potential consignee, andtherefore considered as a consignee within the scope of this and otherembodiments. The consignee's delivery preferences would then beprocessed and applied to all subsequent packages in delivery to theconsignee. These preferences and instructions would be considered asdefault indications. A registered consignee can also indicate aparticular delivery preference for a particular package, which canoverride a standing or default preference. Persons who have notregistered cannot provide a standing preference indication, but canstill provide a per-package preference. Therefore, non-registered userscan be viewed (in some regards) as having a subset of the capabilitiesoffered to a registered user.

A consignee can register and request notification of all impendingdeliveries. In some embodiments, the carrier may store standingconsignee preference information in the consignee profile database 134and per-package preference information in the package level detaildatabase 133. Other embodiments may combine and store both types ofinformation in the consignee profile database 134. A flag indication maybe incorporated in the PLD database 133 indicating that consigneedelivery preferences may apply to delivery of a particular package tothe consignee. Other variations are possible and are within the scope ofthe invention.

Registration, while not a standalone delivery preference by itself, is acapability allowing a consignee to request specific consignee servicesand set certain preferences. Once registered, a user can review, update,or otherwise control their preferences. Thus, registration andindication of delivery preferences may occur together. Once registered,the user may indicate a preference without having to re-register.Consignee registration may be required for processing any of thesubsequent consignee services that a consignee may select. For example,some carriers may not offer a per-package delivery preference indicationservice without registration.

Registration may occur by the consignee accessing the CSS 104 by using aconsignee computer 100 (e.g., a home computer, work computer, etc.) toaccess a web site hosted by the CSS 104, as shown in FIG. 1. Once at thewebsite, the consignee can register as a user of the CSS 104.Alternatively, the consignee may register by telephone 108 directly, orvia contact with a customer service representative 120 by phone or inperson at one of the carrier's shipping hubs or distribution centers.The process of registering may also include authenticating orauthorizing the consignee. For example, the consignee may be required toinput an identifier that is unique to the consignee (e.g., driver'slicense number, social security number, credit card number, etc.). Thisunique identifier can then be verified by the CSS 104 communicating oraccessing a third party database to confirm or verify the information.In general, in any process herein described, whether associated withregistration or other aspects of the present invention, and whetheroccurring via website, telephone, or other access methods, the carriermay require the user to provide authentication information prior toaccepting and processing input affecting the delivery of a package.

FIG. 9 illustrates a typical web screenshot that may be presented toconsignee who is either a user of the CSS 104 or wants to register withthe CSS 104. As shown, the user can provide a unique User ID 902 and apassword 904 for security purposes. Upon logging in 906 or registeringwith the CSS 104, the user is prompted to provide various user profileinformation. The web site can be informative and provide a generalinformation section 1000 briefly explaining the services available tothe consignee. As illustrated in FIG. 10, users may be prompted toprovide user information or contact information, such as their name 1002and address 1004. Certain of this information may be required (such as aname, first address line, city, state, and postal code) and may beindicated in bold text. As indicated above, the CSS 104 may verify andauthenticate that the information provided by the consignee is accurate,such as by accessing a third party database. These portions may berequired to allow the CSS 104 to contact the consignee under variouscircumstances, depending on the services that the consignee selects. Theconsignee may also be required to input his telephone number 1006 and aprimary email address 1008. In various embodiments, the consignee may berequired to provide an alternate email address as well as a passwordsecurity question and answer. An already-registered user may havepreviously provided this information and may be directed to a differentweb page to simply update his preferences.

The system may limit certain services to only certain consignees (e.g.,those with a past minimum level of package deliveries). The services maybe offered at no fee, a flat fee, or a per service (e.g., per-delivery)fee. Tiered service levels may also be provided to a consignee. Billingplans can also vary based on the shipping volume a consignee receiveswithin a particular time frame. Thus, certain high-volume users may notbe charged. Billing can occur on a per-occurrence basis (e.g., chargedto a credit card) or via periodic billing (e.g., charged to apre-established account or mailing a separate invoice).

Delivery Notification

Upon or after registering for consignee services, the consignee mayelect to receive notification (shown as “Delivery Alert” in FIG. 11) offuture deliveries. The notification may occur using variouscommunication means, including email notification and telephonicnotification. Email notification is made using a consignee-providedemail address. This email address may have been provided at the time ofregistration 1008 (see FIG. 10), or at the time that the consigneeselects to receive delivery notification 1110 (FIG. 11). In someembodiments, a plurality of addresses can be indicated, and notificationcan be directed to a personal digital assistant (PDA), cell phone,computer, pager, or other device. Notification can occur using otherforms of electronic messaging, including short message notification,instant messaging, etc. With reference to FIG. 11, the consignee canelect to have email notification sent at the earliest time in which apackage is detected in the carrier's systems 1102, or the emailnotification can be sent within twenty-four hours of the scheduleddelivery 1104. In other embodiments (not shown), email notification canbe sent at some other time in the package delivery process (such as inthe morning of the day that delivery is scheduled). If a consigneeselects to receive e-mail notification 1102 or e-mail reminder 1104, theconsignee may have to enter or confirm his email address 1110 to ensurethat the CSS 104 can send the notification to the consignee.

Telephonic Delivery Notification may also occur, for example, usingautomated equipment to dial a consignee indicated telephone number, andplaying a prerecorded announcement which specifies delivery information.The consignee can select to receive a phone reminder 1106 withintwenty-four hours of delivery. In the embodiment shown in FIG. 11, theconsignee can select a time window option 1108 for receiving the phonereminder. For instance, the consignee can select a morning phonereminder (8 a.m.-12 p.m.), an afternoon phone reminder (12 p.m.-5 p.m.),or an evening reminder (5 p.m.-8 p.m.).

As shown in FIG. 11, the consignee may be presented with variousselection boxes (such as email notification 1102, email reminder 1104,and phone reminder 1106) and may select one or more of these options.For example, the consignee can select to receive e-mail notification andphone reminder, or can select to receive e-mail notification and e-mailreminder, with no phone reminder. Thus, various combinations arepossible, including multiple notifications being sent at differenttimes, or sending multiple notifications via different media and todifferent consignee contacts (such as an email address, via shortmessage service, or a telephone number). The notification alert(s) canalso provide an indication of an estimated delivery time window(s).

Typically, a notification is provided for each package, although otherembodiments may provide a notification for each delivery (which cancomprise a plurality of packages). The notification may include otherinformation, such as the class of service, consignor, weight, value, orany other information retained in the PLD database for the shipment.Typically, notification requires a user to register for the deliverynotification service, although in other embodiments, the notification isprovided on a ‘one-time’ basis, in which the consignor provides theconsignee address information and requests that a notification beprovided to the consignee. The provision by the carrier of deliverynotification is independent of notification provided by the consignor.The carrier may also provide a delivery notification service independentfrom other services requiring registration of a user for purposes ofindicating delivery preferences.

When entering his delivery preferences, a consignee can also selectPackage Release 1112, which authorizes the carrier to deliver thepackage on the first delivery attempt without obtaining a signature.This service is described further below, under “Package Release”.

Delivery Instructions

Upon or after registering, the consignee can select or indicate variousdelivery instructions associated with all future package deliveries, orfor a specific delivery after receiving a notification of that delivery.These instructions may be set by the consignee as default instructionsfor all future package deliveries, specific instructions for a givencondition (e.g., timeframe, specific delivery, etc.), or a one-timeindication (e.g., per delivery or per package). In the last case, theconsignee may be required to provide a tracking number or other shipmentidentifier. In order for the consignee to personalize the deliverypreferences to his specific delivery location, the consignee may berequired to input a “type of address” 1114, such as whether theconsignee lives in a house, or in an apartment (or similar dwelling), asshown in FIG. 11.

The delivery instructions can include, for example, the specificlocation at the delivery address where a package may be left if theconsignee is not present to receive the delivery in person. Referring toFIG. 12A, in one embodiment of the present invention, a consignee wholives in a house, or individual dwelling unit, may instruct the carrierto leave packages at the front door, back door, side door, patio, deck,porch, garage or carport (these options are represented by deliveryinstructions 1200). Alternatively, the consignee could indicate that thepackage is to be left with a neighbor, and provide the street address orapartment number of the neighbor in the space provided 1202. In anotherembodiment, the consignee could indicate that there is no preference forwhere a package should be left. In addition to selecting or providingdelivery instructions 1200, the consignee can manually enter additionalinstructions 1204 for delivery personnel. As an example, theseadditional delivery instructions 1204 could indicate the combination ofa lockbox or gate, or could instruct the delivery personnel to cover thepackage with plastic.

Similarly (and with reference to FIG. 12B), if the consignee lives in anapartment or similar dwelling, the consignee can provide deliveryinstructions 1210 that may be more particular to such a dwelling. Forinstance, the consignee can indicate one of a variety of locations wherethe package could be left, including with the front desk or concierge ofthe apartment building. As described above, the consignee can indicatethat the package is to be left with a neighbor and can input theneighbor's apartment number in the field provided 1212. The consigneecan also provide additional instructions 1214, such as a code to getinto the apartment building, the combination to a secure lockbox, or anindication of the location or combination to another package depository(such as a common delivery location at an apartment complex).

The delivery instructions indicated by a consignee (such as shown inFIGS. 12A and 12B) can be communicated to delivery personnel by thecarrier, by transmitting an appropriate message to a portable computingdevice carried by the delivery personnel, which has a display forindicating text messages or other graphical information of the deliverypreferences selected by the consignee.

After the consignee has provided delivery preferences and deliveryinstructions as described above, the CSS 104 will confirm theconsignee's contact information and indicated preferences andinstructions, as shown in FIG. 13.

As described above, a consignee may initially indicate deliveryinstructions and/or preferences upon registration, so that the CSS 104would apply these instructions and preferences to all future deliveries.As discussed below, the consignee can also modify or update thesepreferences at any time, or can modify them on an individual basis forindividual package deliveries.

Package Release

Upon or after registering, the consignee can also select the PackageRelease service 1112 (see FIG. 11), which allows a consignee to indicatethat a package (or plurality of packages) may be released to thedelivery location on the first delivery attempt without the consignee'ssignature. This is similar to the Advance Delivery Authorization servicedescribed below. This service may be selected by the consignee at thetime of registration or can be indicated on a per-package orper-delivery basis, such as after receiving notification of an impendingdelivery. In some embodiments, the consignor may require a signature,and the consignee's waiver cannot override the consignor's request for asignature. In other embodiments, the carrier may determine that thecircumstances surrounding the delivery are not suitable for release ofthe package without the consignee being present, and thus the packagerelease request may be disregarded.

Delivery Change Request

The Delivery Change Request (DCR) service (see FIG. 14) allows aconsignee to redirect or otherwise impact the delivery of a package(s).In concept, this is similar to the previously mentioned deliverypreference in which the consignee may indicate the package is to be leftwith a neighbor. However, when the change request requires delivery at adifferent stop along a delivery route (e.g., at a distant address), thenthis capability could be viewed as a DCR. Typically, the DCR applies ona per-package or per-delivery basis, although it may be indicated at thetime of registration for future packages that might be delivered to theconsignee within a specified time period, for instance. With referenceto FIG. 14, if the DCR is to apply to a specific package, the consigneewill be required to input the tracking number 1402 of the package.

The consignee can then select from several DCR types, including:redirect package, refuse delivery, reschedule delivery, or will call. A“redirect package” request 1404 instructs the carrier to deliver thepackage to an alternate local address and/or recipient specified by theconsignee when the consignee makes the request. A “return to shipper”request 1406 instructs the carrier to return the package to theconsignor or shipper, and may require a consignee to indicate theconsignee's reasons for return. A “reschedule delivery” request 1408instructs the carrier to deliver the package to the original deliverylocation (e.g., the consignee's home) on a date and/or time specified bythe consignee in the consignee request. A “will call” request 1410instructs the carrier to hold the package for consignee pickup at alocation and for a period of time specified by the consignee in theconsignee request. Those skilled in the art will readily understand thatother instruction options exist that do not depart from the spirit andscope of the present invention. Many of the capabilities and associatedinformation requirements for each of these capabilities are disclosed inthe accompanying figures illustrating how a consignee may indicate theDCR information via a carrier's web site.

In the embodiment shown in FIG. 14, a consignee is limited to selectingonly one DCR per package or delivery. In other embodiments (not shown),a consignee may be able to select more than one DCR. For instance, aconsignee may leave for vacation at a vacation home on the day thatdelivery is scheduled. The consignee could then select “rescheduledelivery” and “redirect package” in order to schedule delivery for twodays later, the delivery to occur at the vacation home.

As shown in FIG. 15, if a consignee selects “Redirect Package” 1404, theconsignee will be directed to a web page to provide the necessaryinformation to redirect the package. For instance, the consignee caninput the name of the company 1502 where the package is to be delivered.The consignee typically is required to provide the recipient name 1504for the “redirect” request. In the embodiment shown in FIG. 15, theconsignee may be redirecting package delivery to his work address ratherthan his home address. In this case, the “recipient name” 1504 is thesame as the consignee's name 1510, namely, John Smith. The consignee mayhave to input or confirm his name 1510 and telephone number 1512. Theconsignee is also required to input the alternate address 1506 for theredirect request. A consignee may be limited to specifying an alternatelocal address, the bounds of which may be determined by the carrier. Forinstance, the carrier can limit the redirect request to an addresslocated along the same delivery route, or an address that is serviced bythe same hub facility.

The consignee may also be required to provide a telephone number 1508for the recipient at the redirected address. The “redirect package”service also enables the consignee to provide special handlinginstructions 1514 that may be associated with the redirect address. Forexample, the consignee may specify that the package is to be left withthe receptionist at the redirect delivery location and input thereceptionist's or office's main telephone number. As shown in FIG. 16,the carrier may direct the consignee to a web page to confirm theconsignee's input information for the redirect package request.

If the consignee selects “Return to Shipper” 1406 (FIG. 14), theconsignee will be directed to a web page (see FIG. 17) to indicate thereason 1700 for returning the package to the shipper. Such reasons maybe that the consignee determined, after the package was in transit, thatthe consignee no longer desires the item. Another reason for return maybe that the consignee needed the package by a certain date anddetermined that the consignor shipped the package too late for it to beof any use. One of ordinary skill in the art may appreciate the varietyof reasons that a consignee may have for returning a shipment to aconsignor after the package has shipped. The consignee may also berequired to provide the consignee's name 1702 and telephone number 1704so that the consignor will have this information when the package isreturned and can associate the information with the shipped package. Asmay be appreciated, because the consignee may have entered thisinformation previously (see e.g., FIG. 10), the CSS 104 mayautomatically fill in these fields on each subsequent web page visitedby the consignee so that the consignee does not have to repeatedly enterthe information. The consignee can also enter special handlinginstructions 1706 for the returned shipment. For example, the consigneecan indicate that the package is to be delivered to the consignor's backdoor. As another example, the consignor could indicate that the packageis to be returned at a lower class of service so that the consignee andconsignor do not have to incur additional costs. FIG. 18 illustrates aweb page confirming the information provided by the consignee in the“return to shipper” delivery change request.

If the consignee selects “Reschedule Delivery” 1408 (FIG. 14), theconsignee will be directed to a web page (see FIG. 19) to indicatecertain instructions for the reschedule delivery request. The web pagemay provide informational instructions 1900 to the consignee andindicate that the new delivery date selected by the consignee must be atleast one day past the scheduled delivery date. The consignee can selecta new delivery date 1902, and input or confirm his name 1904 andtelephone number 1906. The consignee can also confirm or provide specialdelivery instructions 1908 for the rescheduled delivery. As describedabove, the consignee's name and telephone number can be completedautomatically by the CSS 104. Similarly, the special handlinginstructions 1908 can be filled in based on the information provided bythe consignee when indicating delivery instructions (see FIG. 12A,additional instructions 1204, and FIG. 12B, additional instructions1214). If the special handling instructions 1908 are automaticallyincluded by the CSS 104, they can be deleted, changed, or left alone,according to the consignee's preference for the rescheduled delivery.FIG. 20 illustrates a confirmation web page of the reschedule deliveryinformation provided by the consignee.

Finally, if the consignee selects to “Will Call” 1410 the package, theconsignee will be directed to a web page (FIG. 21) to provide additionalinformation. The consignee can confirm his name 2102 and telephonenumber 2104, and can confirm or provide special handling instructions2106. The CSS 104 can automatically determine a carrier facility thatwill hold the package for pickup, based on the consignee's deliveryaddress. For example, the CSS 104 may use the consignee's postal code(provided, for example, as part of the consignee's contact information1002 in FIG. 10) to determine the nearest UPS Store. The web page willpresent the pickup location information 2110 (such as the facility name,address and telephone number) to the consignee. The web page can alsoinclude a hyperlink 2114 to allow the consignee to view a map (discussedbelow) of the carrier facility location. The CSS 104 can also providethe hours of operation 2112 of the carrier facility. The consignee canthen indicate the date or date range 2116 during which the package is tobe held. In various embodiments, the carrier may only hold packages forwill call for a certain period of time (e.g., one week from thescheduled date of delivery), and automatically provide the date range tothe consignee. The web page may include a disclaimer 2118 indicatingthat if the consignee does not pick up the package on the datesprovided, the package will be returned to the shipper.

FIG. 22 illustrates a confirmation web page confirming the consignee'swill call request. If the consignee clicks on the “View Map” hyperlink2114 (FIG. 21), the consignee can be directed to a map showing thelocation of the carrier facility. In the embodiment shown in FIG. 23,the CSS 104 can use the consignee's address and the carrier facilityaddress to provide a map 2300 and directions 2302 to the consigneeindicating how to get to the carrier facility to pick up the package.

Although the Delivery Change Requests discussed above were describedwith regard to the consignee accessing various web pages to provideinformation, other embodiments of the present invention enable aconsignee to provide Delivery Change Request information via telephone.For example, a consignee making a “Redirect Package” request can callthe carrier via the Telephonic Interface (including IVR) 115 and providethe required information using IVR (Interactive Voice Response), or bycommunicating the information to a customer service representative 120who can input the information into a computer 118 in communication withthe CSS 104. In general, any input provided by a consignee (whether fora Delivery Change Request or other request) could also be provided bythe consignor, or an agent designated by the consignee.

Delivery Change Requests can also be made by the consignor rather than,or in addition to, the consignee. A consignor-requested DCR may be madeproactively by the consignor or in response to a request by theconsignee to do so. In the former instance, the consignor may haveplaced the wrong item in the package and indicate a DCR similar to the“return to shipment” DCR described above. In this instance, this DCR maybe a “recall package” DCR, because it is made by the consignor. In thelatter instance, the consignee may realize that he will be at adifferent address at the time that the package is to be delivered.Rather than contact the carrier with this information, the consignee maycontact the consignor and indicate the address to which the package isto be redirected. The consignor can then make a Delivery Change Requeston behalf of the consignee and provide all of the necessary informationfor redirecting the package.

Modification and Updates to Consignee Profile

As discussed above, a registered user of the CSS 104 can update andmodify his user profile, including notification preferences, deliveryinstructions, and delivery change requests, at any time afterregistration (see generally FIGS. 24-27). These modifications andupdates can also occur on a per-package or per-delivery basis. Forexample, in response to an email notification sent to the consignee'semail address, the consignee can access the carrier's website(proactively or through a link provided in the email), provide thetracking number for the package, and indicate certain deliveryinstructions or DCR for the package.

FIG. 24 illustrates a web page allowing a consignee to update his userinformation. The consignee may update his name 2402, telephone number2406, and email address 2408, but would not be able to update hisaddress 2404. Presuming the package is already en route to theconsignee's address, if the consignee wanted to update the deliveryaddress for this delivery, he would have to make a redirect packagerequest as described above. In other embodiments, the consignee may beable to update or modify his address (not shown), but the modificationwould apply only to future deliveries not currently en route to hisdelivery address. The consignee could update other aspects of his userinformation, such as his primary e-mail 2408, alternate e-mail, orsecurity question and answer.

Similarly, the web page illustrated in FIG. 25 would enable theconsignee to update his delivery preferences, as described withreference to FIG. 11. FIG. 26A illustrates a web page enabling theconsignee to update his delivery preferences if he lives in a house.Likewise, FIG. 26B illustrates a web page enabling the consignee toupdate his delivery preferences if he lives in an apartment, town-home,or condominium. FIG. 27 illustrates a web page confirming updates thatthe consignee made to his user information, delivery preferences, anddelivery instructions. Although not specifically shown, it is understoodthat the CSS 104 enables the consignee to update his profile withrespect to a particular package or delivery, in addition to modifyinghis standing or default delivery preferences and instructions. Forexample, the web pages illustrated in FIGS. 24-27 could include a fieldfor inputting the tracking number of a specific package, and theconsignee could be directed through similar web pages to add or modifyany preferences or instructions for the particular delivery.

Carrier Package Processing for Consignee Indicated Personalized DeliveryService

FIG. 2 illustrates one embodiment for processing a package in accordancewith consignee indicated personalized delivery preferences. As may beappreciated, variations and modifications are possible, which remainwithin the scope of the present invention.

The process begins at step 200 with a package being processed by thecarrier's package handling system. The package is typically assigned apackage identifier and encoded with a machine readable form of theidentifier representing a tracking number. Such identifiers are wellknown in the art and used to track a package through the various stagesof handling. Typically, a package is scanned (e.g., ‘read’) severaltimes during its handling by the carrier. Typically this occurs when thepackage is first handled by the carrier, and thereafter at variouspoints when it is loaded and unloaded from a delivery vehicle orprocessed in a package routing center.

At step 202, it is presumed that at some point equipment scans thepackage for determining how to process the package. During this process,the PLD database 133 may be accessed to read/write package level data soas to determine where to route the package. When the package data isread, a determination is made at step 204 whether the consignee haselected to be notified of impending deliveries to the consignee's nameor address. As discussed, this service provides a notification to theconsignee of the pending delivery of the package, typically in the formof an email or telephonic notification message. If the consignee haselected this service, then the next step 206 is to notify the consigneeof the package.

It is common for the email message to provide a link to the carrier'sweb site. The consignee may click on the link to provide preferences orinstructions regarding the delivery of the package. As described above,a registered consignee may update preferences or instructions alreadyregistered with the CSS 104. In other embodiments, an unregistered usercan input or indicate delivery preferences for this particular delivery.In either case, assuming that the consignee has done this, the carrier'scomputing systems at step 208 accept the consignee's deliverypreferences and/or instructions. The carrier then stores thisinformation as a consignee profile, or consignee profile record, in theCSS 104 (such as in the consignee profile database 134) in step 210. Inother embodiments, the carrier could alternatively store the consignee'spreferences in the PLD database 133 as a record for that particularshipment.

The package is presumed to be continued to be routed, until it is loadedon the final delivery vehicle for delivery. Around this time, the CSS104 ascertains whether there are any delivery preferences indicated. Thedetermination of personalized delivery preferences or instructions mayoccur either prior to the package being placed on the delivery vehicle(e.g., while the package is being routed by the carrier's sorting andhandling systems) or after it is placed on the delivery vehicle, or atboth times (such as might occur if the consignee also modifies thepersonalized delivery instructions on the day of delivery). Asillustrated in FIG. 2, the CSS 104 may ascertain whether the consigneehas indicated personalized delivery preferences and instructionsregardless of whether the consignee has elected to receive notificationof the delivery.

The CSS 104 may determine this by querying the consignee profiledatabase 134, or by the accessing the PLD database 133. As noted herein,the indication of personalized delivery preferences and instructions canbe stored either in the PLD database 133 or in the consignee profiledatabase 134, often depending on the type of information to be stored.In the case of the personalized delivery instructions being stored inthe PLD database 133, the CSS 104 can set a flag with that dateindicating exception treatment, so that the information is properlyconveyed to delivery personnel associated with delivery of the package.

Once the determination has been made that a personalized delivery is tobe provided to the consignee in step 214, the CSS 104 determines thespecific preferences and/or instructions indicated by accessing theconsignee profile record (at step 212) in consignee profile database (orthe PLD database, if appropriate). The delivery preferences andinstructions are then communicated by the CSS 104 at step 216 to theappropriate parcel processing system, which typically involvescommunicating the delivery preferences/instructions to the delivery viaa portable computing device (described below). The portable computingdevice then notifies the delivery personnel of thepreference/instruction, typically via a text or graphic messagedisplayed at the appropriate time. If the CSS 104 determines at step 214that no personalized delivery preferences/instructions have beenindicated by the consignee, then the carrier delivers the package to theconsignee under standard delivery procedures at step 218.

Exemplary systems for processing a package in this manner are shown inFIG. 3. In FIG. 3, a package 302 is received by the carrier's packagehandling systems (PHS) 300 which may comprise sortation equipment,package handling equipment, and associated computer and processingsystems for instructing the equipment how to process a package. Suchpackage handling systems 300 include the various systems capable ofidentifying a package via machine readable indicia conveying a trackingnumber, such as disclosed in U.S. Pat. No. 5,804,802, the contents ofwhich are incorporated by reference.

The package 302 is typically scanned or otherwise identified in thenormal handling of a package while in the carrier's sorting facility bythe PHS 300. The scanning equipment, upon identification of the package,may check the consignee's address against consignee addresses stored inthe consignee profile database. This may be accomplished by conveyingthe address via path 306 to the carrier's CSS 104.

Alternatively, the PHS 300 in communication with the CSS 104 maydetermine that an exception exists for the package. For instance, usingthe consignee address, the CSS 104 may communicate with the consigneeprofile database, determine that the consignee has indicated certaindelivery preferences or instructions, and can communicate thisinformation, or ‘exception’, back to the PHS 300. As an example, the‘exception’ may be a delivery instruction by the consignee indicatingthat the package is to be redirected to a different delivery address.

In such cases, the PHS 300 may receive information via communicationlink 306 from the CSS 104 that exception handling is required for aspecific consignee or package delivery. This information could betransmitted periodically on a batch basis for all relevant packages, orindividually for each package as required. Alternatively, the PHS 300,upon notifying the CSS 104 of an address match, may receive anindication from the CSS that special handling is required. In any case,the PHS 300 diverts the package via path 316 to an Exception HandlingCenter (EHC) 312. There, either further processing systems and/orpersonnel determine via information received via communication path 308from the CSS 104 what the ‘exception’ for the particular consignee orpackage may be (for example, that the package should be redirected toanother address). This may entail printing and attaching a new shippinglabel on the package, and forwarding the package via path 318 back intothe normal processing flow 304 of packages. In some embodiments, the EHC312 may be directly notified by the CSS 104 that personalized deliveryfor a package is required. In such cases, the EHC 312 may determine thatthe package is already loaded onto a package delivery vehicle and thepersonalized delivery instructions are communicated using acommunication infrastructure 314 (for example the systems illustrated inFIG. 7) that wirelessly relays the instructions to a portable computingdevice carried by the delivery personnel.

Finally, the CSS 104 may also convey the personalized deliverypreferences or instructions via link 310 directly to the communicationinfrastructure 314 that communicates the information the portablecomputing device used by delivery personnel. These systems help toensure that the portable computing device associated with handling thepackage is notified, at the appropriate time during delivery.

Advance Delivery Authorization

Service Overview

The Advance Delivery Authorization (ADA) service is similar to the“Package Release” service described above. However, the ADA serviceinvolves the use of the electronic delivery authorization form (DAF) forindicating package release. This is another embodiment of the inventionthat provides a personalized delivery experience for the consignee. Invarious embodiments, the DAF is provided in electronic format (such as aPDF file attachment to an email), which can be printed out and posted atthe delivery location for retrieval by the delivery personnelresponsible for delivering the package. Typically, this applies insituations in which the consignee or his representative is not presentto accept a package for delivery, but wants to provide an indicationthat the package may be left at the premises anyway. Currently, aninitial delivery attempt is made, and a paper form is left at thedelivery address indicating the unsuccessful delivery attempt; the paperslip can later be signed by the consignee and left at the deliveryaddress for a subsequent delivery attempt instructing the deliverypersonnel to leave the package. ADA provides the ability to avoid theinitial unsuccessful delivery attempt; in other words, ADA provides theconsignee with the ability to authorize delivery of a package in advanceof a first delivery attempt.

ADA accomplishes this by providing the consignee with advance knowledgeof the delivery, and providing the consignee with a deliveryauthorization form (DAF) which is left at the premises (e.g., on thefront door) in advance of the initial delivery. The delivery personnelmay or may not be aware of the pre-existence of the DAF, but uponencountering the DAF will deliver the package accordingly. Of course,there are some service options which may preclude the use of a DAF(e.g., where the consignor requires a “live”, or in-person, signature,or if the package is COD and requires payment, etc.). It is presumed,for the sake of illustration, that there is no restriction precludingthe use of a DAF.

FIG. 4 provides a high level overview of one embodiment of the AdvanceDelivery Authorization service. In FIG. 4, the CSS 104 is presumed toprovide notification of an impending package delivery to a consignee412. The notification message is viewed by the consignee on theconsignee's computer 100. The notification message may include anattachment including a DAF in any of the well known file formats. Thisallows the consignee to print the form locally, such as at theconsignee's printer 101.

Meanwhile, the CSS notifies a DIAD Updating System 402 that communicatesto a portable computing device 400 associated with the deliverypersonnel. Individual components of the DIAD Updating System 402 will bediscussed in greater detail with reference to FIG. 7. The portablecomputing device 400 is provided information regarding the DAF form,which may be encountered when the delivery personnel 404 attempts todeliver the package 414. The information regarding the DAF form which isprovided to the portable computing device 400 may indicate to thedelivery personnel that a DAF was requested by, or provided to, aconsignee, thus indicating that the delivery personnel should be on thelookout for a DAF at the delivery address.

Upon receiving the notification message of the impending packagedelivery, the consignee may know that he may not be present to acceptthe delivery. Consequently, the consignee fills out and signs the DAF416 and places the DAF 416 in a conspicuous location, such as the frontdoor of the delivery address 420. Upon arriving at the delivery address,the delivery personnel 404 observes and retrieves the DAF 416, and knowsto leave the package according to the instructions or preferencesindicated on the DAF 416. The DAF may have a unique identificationnumber, which the portable computing device 400 may record and/orverify, and which allows the DAF to be associated with the shipment. Insummary, the DAF transforms an otherwise unsuccessful delivery attemptinto a successful delivery.

This is but one variation of the service, as a more complete descriptionof the various embodiments is provided below.

Delivery Authorization Form Generation and Communication to theConsignee

The delivery authorization form (DAF) may be provided to the consigneeby various entities, including the carrier, the consignor, or anotherparty. The DAF is typically provided to the consignee using electroniccommunication, including email, the Internet, or any other communicationmethod known in the art. The consignee may receive the DAF directly(e.g., as an email attachment), or may receive information prompting theconsignee to request the DAF (e.g., by accessing a web site andrequesting the DAF). The consignee may receive this information viatelephone or wireless communication, and then use the consignee'scomputer to access the Internet to retrieve the form. The consignee mayaccess the Internet via dial-up, digital subscriber line (DSL), cableInternet, wireless, or any other means of accessing the Internet knownin the art.

The DAF typically includes fields associated with package delivery, forthe input of information such as the date (e.g., the date that the DAFis signed by the consignee), name and/or address of the consignor,tracking number of the shipment, name of the consignee, address andtelephone number of the consignee, desired package delivery location(such as the consignee's front or back door, garage, a neighbor'saddress etc.), consignee's printed name, and consignee's signature. TheDAF may also include instructions to a consignee for filling out andexecuting the DAF, as well as liability limitations associated withusing the DAF. The DAF may also provide instructions to the deliverypersonnel to follow upon retrieval of the DAF. An individual DAF mayhave an associated serial number. This serial number may be initiallyonly associated with the DAF, and is used by the carrier to associatethe executed DAF with the shipment. This latter association typicallyoccurs at the time of the delivery attempt. Typically, the deliverypersonnel retrieve the DAF upon the delivery attempt and records orreads the serial number in association with the delivery, as describedfurther below.

FIG. 6 illustrates one embodiment of a delivery authorization form (DAF)600, which may be used by a carrier such as UPS. A DAF may include ageneral information field 602 identifying the purpose or name of theform and identifying the carrier. A date field 604 may provide anindication of the date on which the consignee executed the form. Acustomer instruction section 606 provides instructions to the consigneefurther explaining the purpose of the form and how to fill it out. The“Shipping Information” section 608 provides various fields for the inputof a consignor's name or address, a tracking number, a consignee'spersonal information (such as name, address and telephone number).However, a DAF may include more or less information than what is shownin FIG. 6, or may be provided to the consignee with some informationalready completed (rather than the fields being blank). The completionof the form may occur by the carrier or consignor prior to communicationof the DAF to the consignee.

The “Package Location” section 610 may provide personalized deliverypreference information, including pre-printed options as to where thepackage should be left. For instance, the “Package Location” section 610may provide “check-off” boxes for indicating to delivery personnelwhether to leave the package at the front door, back door, patio, oroffice, among other options. The “Package Location” section 610, asshown, also includes the option of requesting that the package be leftwith a neighbor, and provides space for a consignee to indicate theaddress or other description of the neighbor's location. In oneembodiment, not shown, the DAF could include instructions to a consigneeindicating that delivery personnel cannot deliver to an address otherthan the delivery address. This may be because delivery personnel followa pre-planned route for deliveries, and receiving an alternate addressrequest on a DAF may not be compatible with the pre-planned route.

A field may be provided for hand-written information, such as additionaldelivery instructions or preferences, and a signature line is providedfor authorizing release of the package. In other embodiments, theconsignee could complete the Rhin by using an electronic editing tool ona computer prior to printing out the form. For example, in oneembodiment, a consignee may be able to “sign” the form using a computermouse to generally follow the shape of the consignee's signature. Theprocess of providing an Electronic Signature is described further below.

A “Service Provider Instructions” section 612 may be included whichprovides various instructions to delivery personnel regarding how tohandle the DAF. Finally, a “Legalities” section 614 may provide thecarrier's disclaimers or other legal notices.

Other embodiments of the DAF may be of different size, shapes, andconfigurations than the DAF 600 shown in FIG. 6. It is not required tobe sized to fit on a standard 8.5×11 inch sheet of paper, but may besmaller.

Communicating the DAF to the Consignee

Returning to FIG. 1, the consignee can receive the DAF as an electronicattachment in an email message sent from the CSS 104. Alternatively, theconsignee may receive the DAF via a web interface 114, such as byproactively accessing the carrier's web site. In another embodiment, aseparate computer (not shown) may host the carrier's web site andcommunicate with the computing system 122 to provide the DAF to theconsignee. In other embodiments, the consignee can receive the DAF as anelectronic attachment in an email message from the consignor 140, or byaccessing the consignor's web site via the consignor's web interface146.

The CSS 104 can communicate with the consignee's computer 100 andprovide a DAF via email (e.g., as a *.pdf attachment) using the emailinterface 112. Alternatively, the CSS can provide a hyperlink in anemail message for the consignee to access the carrier's web site, or theconsignee can proactively access the web site in order to retrieve theDAF. For consignees that do not have, or choose not to use, a computer,the DAF may be provided in facsimile form via the telephone network 110or other communication method.

The consignee typically communicates via the consignee's computer 100with the consignor's web interface 146. A typical scenario begins withthe consignee executing an on-line purchase of a product. The consignorreceives the order information (such as the product identifier, customeridentification and shipping information, and other informationparticular to the order). The consignor conveys the appropriateinformation to its shipping system 144, which in turn, conveys certaininformation to the carrier. The Internet is often used to convey theinformation to the carrier, typically via the API 150, but otherinterfaces can be used.

The carrier will then use the shipping information to establish a recordfor the package or shipment in the PLD database, which is assigned atracking number. The carrier then provides the tracking number to theconsignor. Thereafter, packages are provided by the consignor to thecarrier bearing the tracking number, allowing the carrier to readilyassociate the package with the PLD information. This may be accomplishedusing well known scanning systems, based on bar codes, radio-frequencyidentification (RFID) tags or devices, etc.

The carrier may communicate an estimated delivery date to the consignorbased on the class of service. This may be communicated to the consignorvia the web interface 114, sending an email message via the emailinterface 112, or via the API 150.

The consignor may then further communicate certain information, such asthe estimated delivery date and tracking number to the consignee. Thistypically occurs via an email message via the consignor's emailinterface 142. Alternatively, the carrier may communicate thisinformation directly to the consignee in an email via the carrier'semail interface 112. In other embodiments, the aforementioned emails mayconvey a hyperlink allowing the consignee to link to an appropriate website to learn of the estimated delivery date.

Possible Service Flows and Operation Configurations

Numerous possibilities exist for communication between the consignor,the carrier and the consignee. FIGS. 5 a and 5 b disclose variousembodiments, and are not intended to be an exhaustive delineation ofevery option.

The embodiments illustrated in FIGS. 5 a and 5 b are predicated on aconsignee ordering an item using the Internet from a merchant (i.e., theconsignor), who then ships the product to the customer. The processbegins at step 500 with the consignee placing an order with theconsignor. This step may occur in several different ways, for example bythe consignee using the consignee's computer to interact via theInternet with the consignor's web site. The consignor typically assignsan identification number to the order and provides the relevant shippinginformation to the consignor's shipping system (see previous discussionassociated with FIG. 1). At step 502, the consignor builds (e.g.,selects and packs) the product. At step 504, the consignor provides therelevant shipping information (such as the consignee's name, address,and telephone number) to the carrier via a shipping system 144 in orderto ship the product via the carrier. The consignor may provide theinformation via the carrier's API 150 and receive in response a trackingnumber from the carrier (not shown).

A package received by the carrier typically bears a label with thetracking number printed in a machine readable form. Such identifiers arewell known in the art and used to track a package through the variousstages of handling. Other forms of package identification, such as RFIDtags could be used. Typically, a package is scanned (e.g., ‘read’)several times during its handling by the carrier. At step 504, theconsignor provides the package to the carrier, and the carrier's packagehandling equipment scans the package for determining how to process thepackage. During this process, the PLD database 133 of the carrier may beaccessed to read or write package level data.

The Advance Delivery Authorization service is predicated on theconsignee knowing, in advance, of the impending delivery. The consigneemay be notified of the impending delivery by the consignor at step 506sending a shipment notification message to the consignee. Typically,when the consignee places an order, the consignee provides an emailaddress so that the consignee can receive such notifications via email.Alternatively, the carrier at step 510 may send a shipment notificationmessage to the consignee. The carrier may know the consignee's emailaddress via a prior registration, as discussed elsewhere herein, or mayobtain this information from the carrier or the package level data.Typically, the message is sent to the consignee by the carrier after thecarrier has determined an estimated delivery date. In either aspect(i.e., at step 506 or step 510), the message to the consignee mayinclude, among other information, the order number provided by theconsignor, the tracking number provided by the carrier, and theestimated delivery date. In other embodiments, the email sent to theconsignee may provide a hyperlink to the consignor's or carrier's website.

At step 508, the consignee may link to the consignor's web site fromeither the email provided by the consignor or from the email provided bythe carrier and proceed to step 560, as discussed in detail below.Alternatively, at step 512, the consignee may link from either email tothe carrier's web site and proceed to step 520, as discussed in detailbelow. In an alternative aspect, the consignee may proactively accessthe web site of the consignor and proceed with step 560, or mayproactively access the carrier's web site and proceed with step 520. Aspreviously mentioned, various authentication information may be requiredby the carrier prior to accepting and processing any informationaffecting the delivery of the package to the consignee.

In one aspect (not shown), the email may also include a deliveryauthorization form for the consignee to fill out and sign, as discussedabove. This form may be provided through an attachment to the email ordirectly in the body of the email in electronic image format, such as*.pdf, *.gif, or other web-transportable image format. The consignee maythen print out the DAF using the consignee's printer. The consignee maythen fill out any necessary information, such as the date, the trackingnumber, the consignee's name, address and phone number, the name of theconsignor, and the desired delivery location, among other information.The consignee then signs the form. Alternatively, the consignee can fillout this information using the consignee's computer. The consignee thenprints out the completed form and signs it. The consignee can then affixthe signed DAF to a delivery location or site, such as the consignee'sfront door. The delivery would occur under ordinary procedures, and thedelivery personnel would retrieve the signed DAF upon delivery of thepackage and deliver the package according to the indications made by theconsignee on the DAF.

In another aspect of this invention, the consignor may have registeredwith the consignee services system 104, as described above, and chosento receive notification of inbound packages and indicated deliverypreferences. When the consignor provides the relevant shippinginformation to the carrier at step 504, this information may be updatedto the carrier's PLD database. The PLD database 133 may then communicatewith the Consignee Profile Database 134 to determine if the consigneehas registered with the CSS 104. Assuming the consignee has chosen toreceive notification messages for shipments bound to the consignee'sname or address, the CSS 104 triggers a notification message to be sentto the consignee. This automated notification typically includes atracking number, service, reference number, or scheduled delivery date.The notification message may also include a delivery authorization formprovided as an attachment to an email in an electronic image format,such as *.pdf, *.gif, or other web-transportable image, or provided viaa hyperlink to the carrier's web site. The DAF may already indicatecertain shipment-specific information, such as the name of theconsignor, the consignee's name, address and telephone number, thetracking number, and an associated DAF serial number. The consigneeprints the DAF directly from the email and signs it, without having tofill out manually any information other than the date, and places theDAF at the anticipated delivery location for the delivery person toretrieve.

Advanced Signature Authorization via Carrier's Web Site

At step 512, the consignee accesses the carrier's web site, eitherthrough a hyperlink provided in an email from the consignor or thecarrier, or proactively. The carrier's web site may present to theconsignee a summary of the shipment, including its status, estimateddelivery date, tracking number, consignor, etc. At step 520 theconsignee confirms the status of the shipment. At step 522, theconsignee may determine that he will be unable to receive the deliveryon the estimated delivery date and therefore requests a DAF from thecarrier. At step 522 the carrier's CSS 104 will generate a DAF. The stepof generating the DAF may include completing various fields of the DAF.For instance, because the CSS 104 is in communication with the PLDdatabase 133, it can retrieve the package level data (e.g., theconsignor's information, the package tracking number, the consignor'sname and address), and can populate the fields (described above withreference to FIG. 6) of the DAF with this information. Alternatively,the carrier can simply generate a blank DAF. In either case, the carriertransmits the DAF to the consignee (typically via the Internet, althoughother means can be used) at step 526.

A completed or semi-completed DAF may include the tracking numberassociated with the shipment, and a serial number associated with theDAF. If the consignee has registered certain delivery preferences withthe CSS 104, the DAF may also reflect these preferences, includingspecialized delivery instructions such as where the delivery personnelshould leave a package when the consignee is not home. The personalizeddelivery preferences determined by the carrier may be based on thepreferences retained in the consignee profile database 134.Alternatively, the consignee can fill out the DAF to instruct orindicate to the delivery personnel to leave packages at the front door,back door, side door, patio, deck, porch, garage, carport, neighbor'shome, or other special delivery instructions.

Thus, the DAF generated at step 524 may be personalized to theparticular consignee and particular shipment. The CSS will then send theDAF to the consignee at step 526, typically via email. Alternatively,the web site may provide the consignee with an electronic image of adelivery authorization form, such as *.pdf, *.gif, or other webtransportable image. The consignee may then retrieve the electronicimage of the DAF. Upon receiving the DAF, the consignee may proceed withstep 580 in printing out the DAF using the consignee's printer. If theCSS 104 generated much of or all of the necessary information for theDAF at step 524, the consignee needs only to print out the DAF, fill inany missing information, such as the date, and sign the DAF.Alternatively, if less than all necessary information was generated andincluded in the DAF at step 524, the consignee may then fill out anymissing and/or necessary information, such as the tracking number, theconsignee's name, address and phone number, and the name of theconsignor, among other information. The consignee may then sign theform. Alternatively, the consignee may fill out this information usingthe consignee's computer 100 prior to printing. The consignee may thenprint out the completed form and sign it.

The consignee can then affix the signed DAF to a specific location orsite at the delivery address, such as the consignee's front door (step582). At step 584, the delivery would occur under normal procedures, andthe delivery personnel would retrieve the signed DAF upon delivery ofthe package, and would know to deliver the package according to theinstructions indicated on the DAF. Different procedures for deliverypersonnel to take upon and after delivery of the package are discussedin more detail below.

Returning to step 520, the consignee may alternatively request providingan online signature (step 530) to authorize delivery of the package. Ifthe consignee requests to provide an online signature, the carrierwebsite may require that the consignee agree to certain legallimitations or liabilities associated with providing an onlinesignature. For example, the carrier website may provide “Terms andConditions” which the consignee may have to agree with by clicking on abox indicating “I agree” with the Terms and Conditions. Both the carrierand consignor may require this legal authorization from the consignee.In one embodiment (not shown), the carrier (or consignor) may requirethat the consignee have a signature on file with the carrier in order toprovide an online signature. For example, the consignee may have toprovide a paper (i.e., hand-written) signature to the carrier prior torequesting the online signature option. The carrier may also provide theconsignee with language regarding the legalities or liabilities ofproviding a paper signature to authorize future online signatures.

At step 532, the carrier's CSS 104 would then confirm whether or not anonline signature would be accepted to authorize delivery of thispackage. This can include the CSS 104 communicating with the consignorsystem 152 to determine if an online signature is acceptable.Alternatively, this information may be part of the package level data,and the CSS 104 can communicate with the PLD database 133 to determineif the online signature is acceptable. If not accepted, at step 534 thesystem notifies the consignee of the denial of the online signaturerequest and provides the consignee with the option of using a DAF toauthorize delivery of the shipment. The system may provide this optionin many different ways, such as automatically sending an email to theconsignee including a DAF, or automatically providing the consignee witha message on the carrier's web site stating that the online signaturerequest has been denied and providing an online, printable DAF. If theonline signature is authorized, at step 536 the consignee would providehis online signature. This may be done by providing an electronic ordigital signature or other method known in the art.

If the online signature is accepted at step 534, it can be provided invarious ways, as described further below. For example, the “onlinesignature” may be provided simply by the consignee clicking on a boxagreeing to certain legal “Terms and Conditions”. In other embodiments,the consignee may be directed to a web page having a graphic box toindicate his signature using a mouse or other pointing device, asdescribed below. Once the signature has been accepted by the carrier,the carrier system updates the shipment information in the PLD database(step 548) to indicate that an authorization signature has been providedfor package release. If the package had not yet left the shippingfacility, this information would become part of the package level dataand would authorize the delivery personnel to deliver the packagewithout requiring a signature at the time of delivery.

Alternatively, if the package were already en route to the consignee,the updated PLD information may be communicated to a portable computingdevice associated with delivery personnel delivering the package, suchas the DIAD (Delivery Information Acquisition Device) carried bydelivery personnel of UPS. The DIAD is typically uploaded withinformation for the carrier's package processing systems for eachpackage scheduled to be delivered. Aspects of the DIAD are disclosed inU.S. patent application Ser. No. 10/227,147, filed Aug. 23, 2002, thecontents of which are incorporated herein by reference in theirentirety. The CSS 104 may communicate any generic delivery informationor package specific information to a package processing system, which inturn forwards the information to the DIAD when there is an update in thedelivery information for the consignee or the shipment. Informationconveyed to the DIAD can be of various forms, including notes, alerts,or procedural details associated with the indicated consignee (discussedfurther below). The delivery personnel will then have information thatan online signature has been provided at or before the time of delivery,and will deliver the package (step 550) without requiring a signaturefrom the consignee upon delivery.

In another embodiment, upon accessing the status of the shipment via thecarrier's website (step 520), the consignee may request signature waiver(step 540) to effect a Package Release. The Package Release allows aconsignee to indicate that a package (or plurality of packages) may bereleased without the consignee's signature. The carrier may thencommunicate with the consignor to determine if it is allowable for thesignature to be waived (step 542). Alternatively, whether or not asignature is required may be part of the package level data stored inthe PLD database 133. As another example, the carrier may havepreviously received information from the consignor indicating that asignature is required and may not be waived. If, at step 544 thesignature waiver is approved, the CSS would update the PLD database withthis information and continue in accordance with step 548, describedabove. If the signature may not be waived, the package may be deliveredaccording to ordinary delivery procedures, and a signature would berequired from the consignee at the time of shipping (not shown).Alternatively, at step 546, the carrier may communicate an updatednotification message to the consignee indicating that signature waiverhas not been accepted. The message may include an attachment of adelivery authorization form in electronic image format, such as *.pdf,*.gif, or other web-transportable image, or may include a hyperlink tothe carrier's website which would provide online access to a DAF. Theconsignee may then proceed according to step 580.

Advanced Signature Authorization via Consignor's Web Site

Returning to step 508, the consignee can access the consignor's web sitethrough a hyperlink provided in an email from the consignor (or thecarrier) or proactively, and can then proceed to step 560 where theconsignee may confirm the status of the shipment. The consignor'swebsite may provide a hyperlink to the carrier's website via path 562,after which the consignee would proceed with step 520 as discussedabove. Alternatively, the consignor and carrier's web sites may belinked through the APIs between the carrier and consignor's computers,and the consignor may request the shipment status information from thecarrier by path 562 and the carrier may return the shipment statusinformation to the consignor via path 564 to be displayed on theconsignor's web site.

The consignee may then request signature waiver at step 570. If theconsignor authorizes waiver of the signature requirement, the consignorcommunicates this information to the carrier (step 572). This may becommunicated via email, through the Internet via the web interface ofboth the consignor or and the carrier, via the APIs, or through anyother means known in the art. The carrier would then proceed as in step548 in updating the PLD database 133 with the information that thesignature requirement has been waived. Delivery personnel would thendeliver the package without requiring a signature from the consignee atthe time of delivery (step 550).

Returning to step 560, according to another embodiment of the presentinvention, upon confirming shipment status through the consignor's website, the consignee may request a delivery authorization form at step574. The consignor's web site may then provide a means for the consignee(path 566) to access directly the carrier's web site to obtain the DAFand proceed as in step 524. The consignor may provide this link to theconsignee via an email, through a hyperlink on the consignor's web site,or through any other means known in the art. Alternatively, theconsignor's system communicates with the carrier's web site via path 566(such as by accessing the carrier's system via the API) and requests theDAF from the carrier. The carrier would then generate the DAF (includingany related information, such as the consignee's name, address andtelephone, and the tracking number of the shipment, among otherinformation). The DAF may also include a serial number associated withthe DAF, as will be discussed in more detail below.

The carrier would then communicate the DAF to the consignor via path 568(such as, for example, via the consignor's API 147). The consignor thenprovides or transmits the DAF to the consignee in step 576. Theconsignor may provide the form to the consignee as an attachment to anemail in electronic image faunat, such as *.pdf, *.gif, or otherweb-transportable image format, or may provide a hyperlink to allow theconsignee to access an online version of the form. The consignee wouldthen proceed to step 580 as discussed above.

When the consignor provides the consignee with a DAF at step 576 (orpossibly when the carrier provides the DAF at several points in thesystem), the DAF may or may not include an associated serial number.Several possibilities for the inclusion or exclusion of a serial numberon the consignor-provided DAF are described below. The procedures usedby the delivery personnel depend on the presence of a serial number onthe DAF. The DAF may be completely filled out, signed, dated, and havean associated serial number, in which case delivery would proceed undernormal delivery procedures.

As discussed earlier in conjunction with FIG. 4, under normal deliveryprocedures, updated consignee preference information may be communicatedto delivery personnel delivering the package via a portable computingdevice 400 such as the DIAD. When the CSS associates a serial numberwith the DAF at step 524, the CSS may update this information to theDIAD Updating System 402 (of FIG. 4) and indicate that the consigneewill be using a DAF and provide the serial number of the DAF. The DIADUpdating System 402 will then communicate this information to the DIAD400 (of FIG. 4) of the delivery personnel delivering the package. Upondelivering the package and retrieving the DAF, the delivery personnelmay scan the DAF and the DIAD confirms that the serial number of the DAFis the serial number that was associated with the shipment by the DIADUpdating System 402. If the DIAD Updating System 402 has not updated orotherwise communicated the serial number to the DIAD 400, the deliverypersonnel may scan the DAF as an initial association of the serialnumber with the shipment.

Electronic Signature via Carrier's Web Site

FIG. 28 illustrates an embodiment of a consignee providing an ElectronicSignature at the carrier's website. As can be seen, at Step 1, thecustomer (e.g., the consignee) can log into the consignor's website,such as to check the status of the consignee's order. At the consignor'swebsite, the consignee can click on a hyperlink to link to the carrier'swebsite. At step 2, the carrier website pre-populates shipmentinformation, which has previously been stored in the PLD database. Asdescribed throughout, the shipment information can be the trackingnumber of the package or shipment, the address of the consignee, aunique identifier for the consignee, etc. At step 3, the consignee logsinto the carrier website and is presented with a DAF, which includes thedata that was pre-populated at step 2. At the carrier's website, theconsignee is presented with a graphic box in which the consignee canprovide a digital signature. For example, the consignee can use acomputer mouse or other pointing device (e.g., trackball, trackpoint,etc.), to sign in the box. In other embodiments, an electronic signaturecould be provided by selecting or clicking on a box indicating that asignature thereby provided, or by typing the consignee's name into atext box and indicating that the typed name represents the consignee'ssignature. The carrier's website may also include an authenticationfeature (not shown) to verify that the person providing the signature isthe consignee (or an authorized representative of the consignee). Forexample, the carrier's website may require that the consignee providehis social security number, driver's license number, a credit cardnumber, or any other identifier which would be unique to the consignee.The carrier could then authenticate the consignee by verifying theinformation with a third party or third party database.

The consignee may also complete any information on the DAF that was notpre-populated by the carrier. The CSS 104 captures this electronicsignature and stores it (along with any additional information completedby the consignee). The electronic signature may be stored as “inactive”at this time, as it has not yet been associated with or used to releasethe delivery of the package. In one embodiment, this information may bestored in the PLD database. In other embodiments, some or all of thisinformation could be stored in the consignee profile database. Once thecarrier website captures the electronic signature and other information,the completed DAF is presented to the consignee. At step 4, theconsignee can print the signed DAF and post it at a location at thedelivery address (such as at the front door).

Upon delivering the package to the consignee, the delivery personnelretrieves the DAF, and can scan it using a portable computing device,such as the DIAD. In the embodiment illustrated in FIG. 28, the DAFincludes machine readable indicia that can indicate the tracking numberand/or the unique serial number for the DAF. As described throughout,this step serves to associate the package with the DAF. The driver thenreleases the package.

At step 6, the delivery information is uploaded to the DIAD CaptureSystem (DCS, described further below). At step 7, the CSS 104 solicitspackage status information from the DCS for all packages shipped fromthe consignor, based on tracking numbers. The solicited data isretrieved from the DCS and the results are returned for all deliveredpackages at step 8. This information can then be stored in the PLDdatabase. At step 9, the electronic signature provided at step 3 will beretained or overridden, depending on certain parameters. If the deliverypersonnel released the package based on retrieving the DAF including theelectronic signature, then the electronic signature will be retained andstored, and will remain associated with the DAF. However, the consignee,when completing the DAF, may have indicated that delivery was to occurat a neighbor's address. If the delivery personnel releases the packageto the indicated neighbor, the delivery personnel may obtain a signaturefrom the neighbor on an additional DAF. This signed DAF, and itssignature, would override the electronic signature provided by theconsignee. Similarly, the consignee may have thought initially that hewould not be home to accept delivery, and thus may have completed andsigned a DAF at step 3. For various reasons, however, the consignee mayactually be present at the time of delivery and can provide a “live”signature. Upon receiving the “live” signature on the DIAD, thissignature will override the electronic signature provided at step 3. Theconsignee's electronic signature can then be removed from the databasein which it was stored.

At step 10, the consignor can log into a secure carrier website and beprovided with a visual representation of the signed DAF. The consignorcan then print the electronic DAF with the electronic signature and keepthis DAF for the consignor's record. Similarly, the carrier (e.g., via acustomer service center or representative), can access the carrier website and retrieve the DAF and associated information and signature. Thismay be useful for updating data associated with the consignee orshipment in the consignee profile database and PLD database.

Possible Schemes for Associating a Serial Number to a DAF

The possibilities described below are representative only, and do notpreclude other possibilities or combinations thereof, as may come tomind to one skilled in the art.

Possibility 1: Serial Number not Included on the Daf or not Provided toConsignee

In the situation where the DAF does not have a serial number associatedwith it, several options for delivery procedures exist for the deliverypersonnel to follow. For instance, delivery personnel may select aserial number to associate with a DAF at the time of delivery. Thedelivery personal may select the number by copying the number from anexisting paper-based delivery notice or selecting a value stored in theDIAD. The delivery personnel would manually write the number on the DAF.Alternatively, the delivery personnel may have a roll or sheet ofstickers with a sequential serial number printed on each sticker, whereeach delivery personnel has a different range of serial number stickerssuch that the delivery personnel may peel a sticker from the sheet orroll and affix it to the DAF. The delivery personnel may then enter thisserial number into the DIAD to associate the value with the DAF. Inaddition, the sticker may provide the serial number in a bar code orother machine readable form, such that the delivery personnel may scanthe sticker and scan the package to associate the serial number with thetracking number. As another alternative, when the delivery personnelreturns to the carrier's facility, the serial number that was manuallyentered onto the DAF or the serial number of the sticker that wasaffixed to the DAF may be communicated to the CSS and/or other carriersystems.

A second option for delivery personnel to associate a serial number witha DAF that does not already have an associated serial number is for thecarrier to provide its delivery personnel with a stack of blank DAFs sothat when a delivery personnel encounters a DAF that does not have anassociated serial number, he may take a DAF (similar to the existing UPSInfoNotice® forms) from his stack of blank DAFs and associate thatserial number to the signed DAF. As an example (as illustrated in the“Service Provider Instructions” in FIG. 6), the delivery personnelencounters a DAF without a serial number. The delivery personnel maythen retrieve a blank DAF (e.g., UPS InfoNotice®) from the providedstack and scan that DAF using a scanning device. The delivery personnelmay then place the scanned, serial number-associated DAF at the deliverylocation to indicate that the package was delivered and that the signedDAF was retrieved, and the delivery personnel may then manually writedown the serial number of the scanned DAF in a space provided on thesigned DAF. The delivery personnel may then return to the carrierfacility and provide the signed DAF with the manually entered serialnumber to the records facility for updating in the CSS. As an additionalmeasure, the delivery personnel may scan the serial number of the blankDAF and scan the package, so that the serial number and tracking numberof the shipment are associated in the system, and when the deliverypersonnel returns to the carrier facility with the signed form and themanually entered serial number, the records center need only verify theassociation of the serial number and the tracking number.

Another option for associating a serial number to a DAF that has beensigned but does not have an associated serial number is for the deliverypersonnel to communicate with the CSS at the time of delivery (such asvia the DIAD). The delivery personnel may input the tracking number ofthe package or shipment into the system, the CSS would process thisinformation, such as by accessing the PLD database in order to retrievethe package information and generating an associated serial number, andthen would return a serial number to the delivery personnel (such as viathe DIAD) for the delivery personnel to associate with the DAF. Thedelivery personnel may then manually write down the serial number in aspace provided on the DAF. In this aspect, the CSS may have alreadyassociated the tracking number and the provided serial number, such thatwhen the delivery personnel returns to the carrier facility with thesigned form and the manually entered serial number, the records centerneed only verify the association of the serial number and trackingnumber.

Possibility 2: Carrier Provides Consignor with Predetermined Range ofSerial Numbers

A second possibility is that the carrier may have assigned a range ofserial numbers to the consignor to allocate as required. The carrierwould have to allocate each consignor unique values to avoidduplication. This allows the consignor to directly provide the consigneewith a DAF with a serial number from the predetermined range. Thisavoids the consignor at step 360 having to communicate with the CSS atpath 370 to request a DAF with an associate serial number. Thus, if forsome reason the consignor's system was unable to communicate with thecarrier's system at paths 370 and 372, the consignor could still providea serial number-associated DAF to the consignee upon the consignee sorequesting at step 360. Alternatively, if the consignor requests a DAFfrom the carrier at path 370 and the generated DAF that that the carriersends back to the consignor does not include a serial number, theconsignor may associate a serial number from the predetermined range tobe associated with this DAF. The consignor may somehow manipulate theDAF to include the serial number (such as by editing the electronicimage to include the serial number), or may provide it to the consigneeand instruct the consignee to fill in the serial number manually on theDAF.

Alternatively, if the consignor requested a DAF from the carrier at path370 and the carrier generated DAF related information including a serialnumber, or if the carrier sent the DAF with minimal informationincluding at least a serial number, the consignor could provide thisserial number-associated DAF to the consignee at step 362 and not haveto assign a serial number from the predetermined range of numbersprovided by the carrier.

Delivery under Possibility 2 would occur under normal procedures. Thedelivery personnel may retrieve the signed DAF and scan in the serialnumber, such that the serial number is associated with the trackingnumber in the CSS. Alternatively, the delivery personnel will return tothe carrier's facility and may provide the DAF to the records center sothat the serial number may be officially associated with the shipment inthe carrier's system.

Possibility 3: Carrier Assigns Individual Serial Numbers to Each DAFRequested by the Consignor

A third possibility would allow the consignor and carrier systems to bein communication (such as via the API of each system or the webinterface of each system), such that every time a consignee requests aDAF from the consignor at step 360, the consignor would communicate withthe carrier via path 370 and the carrier would generate a serial numberat step 304. The carrier would communicate this information back to theconsignor via path 372.

If a serial number was provided and included on the DAF, delivery underPossibility 3 would occur under normal procedures. The deliverypersonnel may retrieve the signed DAF and scan in the serial number,such that the serial number is associated with the tracking number inthe CSS. If a serial number was not provided from the carrier to theconsignor, delivery personnel may follow the delivery proceduresoutlined in Possibility 1.

Example Application of Advance Delivery Authorization

A description of the systems and methods for providing a consignee withAdvance Delivery Authorization is now provided using one embodiment ofthe present invention. This description represents one possible methodof a consignee using the service, and does not represent all possiblevariations of the service or possible events that can occur.

A consignee orders a product from a consignor by accessing theconsignor's web site. Upon ordering the product, the consignee providesrelevant information, such as the consignee's name, address, emailaddress, phone number, and other identifying information, comprising theorder and/or shipping information. The consignor associates an ordernumber with this order. The consignor provides the appropriate shippinginformation to the carrier and is provided with a tracking number. Thepackage is provided to the carrier bearing the tracking number.

The carrier then processes the package, and through existing proceduresnotifies the consignee of the anticipated delivery date of the package.The notification may include a hyperlink or other link to the web siteof the carrier as well as the tracking number. The consignee may thenclick on this link or otherwise use the link to connect to the web siteof the carrier. Alternatively, if the consignee has previously receiveda tracking number or other shipment identifying number, the consigneemay proactively access the web site of the carrier and indicate thetracking number.

Upon accessing the carrier's website, the consignee confirms the statusof the shipment. The carrier's web site provides information such as thetracking number, the number of packages in the shipment, and informationas to where the shipment is in the delivery process (such as at a hubawaiting delivery, en route, etc.). The shipment status typicallyprovides an estimated time and/or date of delivery. Assuming theconsignee determines he is unavailable at the expected delivery time,the consignee requests a DAF from the carrier's web site.

The CSS generates a DAF, which includes the tracking number, theconsignor's name and address, the consignee's name, address andtelephone number, and a serial number. The DAF may also include specialdelivery instructions that the consignee may have previously provided tothe carrier, such as the preferred delivery location or site. Upongenerating the DAF, the CSS would provide the DAF to the consignee viathe carrier's web site, so that the consignee may print the DAF directlyfrom the web site. Alternatively, the CSS may provide a hyperlink to thecarrier's web site where the DAF would be available for the consignee toprint. Another alternative would be for the CSS to generate an email tothe consignee that would include the DAF as an attachment or in the bodyof the email.

The CSS may then update the DIAD Updating System 402 and indicate that aDAF and associated serial number was generated for the consignee. TheDIAD Updating System 402 will then communicate this information to theDIAD of the delivery personnel at the appropriate time of the day of thepackage's delivery (discussed further below).

After the consignee prints the DAF provided from the carrier, theconsignee may fill in any information that may not have been filled inby the carrier (such as if the consignee has an alternate phone numberthat had not been previously associated with the shipment, or analternate delivery location that differs from the location as providedin the consignee's special delivery preferences). The consignee signsand dates the form. The consignee attaches the DAF to the anticipateddelivery site (such as the consignee's front or back door).

The delivery personnel retrieves the signed DAF at the time of deliveryand then delivers the package. The delivery personnel may scan the DAFto read the serial number and confirm it is the serial number indicatedin the DIAD for this particular delivery.

Carrier Provided Personalized Delivery Information (CPPDI)

Heretofore described, the information provided to the DIAD (or otherportable computing device) has been personalized delivery informationthat originated from the consignor, or the consignee. There is anothercategory of information that may be provided to the DIAD in conjunctionwith a package delivery that originates from the carrier itself. Thisinformation is known as carrier provided personalized deliveryinformation, or CPPDI.

Typically, carrier delivery personnel are responsible for deliveringpackages along a regular route. In many instances, the deliverypersonnel become familiar with the route and develop a personalknowledge of the route, the consignees along the route and theirdelivery preferences, and other information pertaining to packagedelivery along the route. For example, the delivery personnel may knowthat a particular elderly consignee has a health condition (e.g., a badback), and that packages should be left on a table at the front door.The elderly consignee may not have communicated this information to thecarrier via the aforementioned systems or methods, but may have informedthe delivery personnel in person at some point in time (such as at thetime of a prior delivery). The delivery personnel may also know thatcertain consignee homes may be frequented by a dog or other animal. Thistype of information is often “stored” mentally by the deliverypersonnel, but in the case of the regular delivery personnel beingreplaced or substituted with a temporary driver, this information isunknown to the temporary driver.

Thus, the same infrastructure and systems, described above, that storeand process delivery preferences and instructions of consignees andconsignors, can also be the basis for storing and providing otherinformation. This other information may be information observed by thecarrier (e.g., the delivery personnel) at certain delivery addresses,specific route information (such as road conditions or detours), etc.Thus, if a regular delivery personnel is sick, a temporary or substitutedriver can be provided with this carrier-provided information. Thisinformation can be provided by the carrier to the DIAD of the deliverypersonnel (regular and temporary) of various delivery routes to aid thedelivery personnel with completing the delivery.

Types of Customized Pickup and Delivery (CPaD) Data

The personalized delivery preferences and instructions provided by theconsignee and consignor, as well as the CPPDI described above, can becollectively referred to as Customized Pickup and Delivery (CPaD) data.Generally, CPaD data can be categorized into at least three types:Procedures, Alerts, and Notes. The distinction between the categoriestypically involves what information is conveyed and how and when it isprocessed by the carrier systems and the DIAD. In other embodiments,more or fewer categories can be defined. The following distinctions arenot intended to limit the categories of information, but rather providegeneral guidelines as to what information falls into which category.Additionally, CPaD data may not necessarily be communicated to the DIADas part of these categories, but may be sent to the DIAD in a differentway or at a different time than described throughout.

Alerts are one type of CPaD data that comprise information that must beaddressed by the delivery personnel. Generally, alerts must be addressedbefore the delivery to a consignee is completed, or before the deliverypersonnel proceeds to the next stop on the delivery route. One exampleof an Alert may be an indication that a delivery is COD(Cash-on-Delivery) and notifying the delivery personnel that onlycertified check or money order can be accepted from the consignee. Inone embodiment, the DIAD displays an icon to the delivery personnelindicating that an Alert is involved with the delivery. Because thedelivery personnel must address an Alert, certain screen functions ofthe DIAD may be interrupted or blocked until the delivery personaddresses the Alert (i.e., reads, review, and/or acknowledges orresponds to it).

Notes are another type of CPaD data. Notes involve information that isof a general informational nature. Typically, notes comprise informationthat can be bypassed, in that the delivery personnel are not required toacknowledge or respond to the information before proceeding with thedelivery or other deliveries. An example of a Note may be a messageindicating that a large dog is present at the consignee deliveryaddress, and that the delivery personnel should beware of the dog. Thistype of message is informational only, and can be read and bypassed bythe delivery personnel without any specific action being taken on thedelivery personnel's part.

Procedures are another type of CPaD data that provide information todelivery personnel indicating a certain procedure or protocol that needsto be followed for delivery of the package. In many instances,Procedures accompany Alerts and/or Notes. For example, if an Alert issent to the DIAD indicating that a package is COD, once the deliverypersonnel acknowledges the alert, he may be presented with certainProcedures to follow for the COD delivery. For instance, a Proceduremessage can remind the delivery personnel to obtain proof ofidentification before accepting a check or money order for a CODdelivery. Similarly, if a Note is sent to the DIAD indicating that alarge dog is usually present on the premises, and Procedure might followindicating that packages can be left on the front porch to avoidencountering the dog.

It can be appreciated that Alerts, Notes, and Procedures can indicatevarious messages or information to delivery personnel, and can be sentto the DIAD in conjunction with each other in order to convey thisinformation. Alerts, Notes, and Procedures can be presented on the DIADin the form of text and/or graphics (e.g., including icons). Theinformation can be in the form of ‘canned’ text or free-form text. Thus,certain common types of information (i.e., those Alerts, Notes, andProcedures that arise many times and generally not with reference to anyspecific consignee or delivery) can be provided as ‘canned’ text to thedelivery personnel. For example, an Alert indicating that the deliverypersonnel must scan machine readable indicia on a DAF before proceedingwith the next delivery may be ‘canned’ text. On the other hand,information that is more specific to a certain delivery or consignee,and is not commonly encountered, can be provided as determined by theoriginator of the message (e.g., in free-form text). Thus, the CSS 104may have to generate a free-form Note to indicate that a large dog ispresent at the consignee's delivery address. Additionally, audiblealarms (e.g., sounds, beeps, etc.) can be used in addition to text oricons, allowing the DIAD to provide an additional indication to thedelivery personnel of the presence of CPaD data.

Triggering Alerts, Notes and Procedures to the DIAD

The distinction between Alerts, Notes and Procedures lies not only inthe different type of information that each of these messages provide,but also in the ways in which the information can be triggered to besent to the portable computing device (e.g., DIAD) carried by thedelivery personnel. Alerts, Notes and Procedures can be triggered basedon whether the delivery personnel is performing a delivery, a pickup, ora combination delivery and pickup. Alternatively, Alerts, Notes andProcedures can be triggered only during certain days of the week, forcertain delivery addresses, only if the delivery personnel is atemporary driver (as opposed to the ‘regular’ driver), etc. Thus, therecan be any number of criteria to trigger Alerts, Notes and Procedures tobe sent to the DIAD.

As an example, a regular driver may notice that a large dog is alwayspresent at a particular address. The driver may contact the carrier(e.g., via the DIAD, or via a customer service representative, etc.),and inform the carrier that CPPDI should be entered into the carriersystems to indicate the presence of the dog at the address. In CSS 104can then trigger this information to be presented in various ways. Inone instance, the CSS 104 can trigger this information only if atemporary or new driver is delivering or picking up a package at thisaddress. This message would likely be triggered in the form of a Note sothat no response would be required by the driver, and would be triggeredregardless of the day of the week.

As another example, a pickup location may be closed for two weeks due toa fire at the location. This information may be provided to the deliverypersonnel in the form of an Alert, and require that the deliverypersonnel acknowledge the message. Because this situation may affect thedelivery personnel's delivery and pickup route for the day, this messagemay be triggered to be sent to the DIAD at the beginning of the deliverypersonnel's shift, and may be sent each day that the pickup location isclosed. This information likely would be sent regardless of whether thedelivery personnel is the regular driver or a temporary driver.

As another example, the DIAD typically provides the delivery personnelwith a list of items to be delivered and picked up along the deliverroute that day. This list can be presented to the delivery personnel atthe beginning of the shift as general information. In this instance, thedelivery personnel can view the list of pickup and delivery stops thatneed to be made, and can view any Alerts, Notes and Proceduresassociated with each stop, or with the day's route, at the beginning ofthe shift. These same Alerts, Notes and Procedures, however, can betriggered to be presented when the delivery personnel arrives at eachpickup and delivery location as well.

Thus, there are numerous combinations of the ways and times at whichCPaD data can be triggered to be sent to the DIAD.

Systems for Storing and Triggering CPaD Data to the DIAD

The above examples presume that CPaD data has been properly loaded intothe DIAD for the current day's deliveries and pickups. This requiresthat the CPaD data be maintained in various information systems of thecarrier so that the information can be downloaded properly to the DIADat the necessary times.

FIG. 7 illustrates an exemplary carrier system including severalinformation systems which are involved in providing CPaD data to theDIAD, as described above. The Dispatch Planning System (DPS) 700 is thesystem that defines the routes taken by various package deliveryvehicles in any given territory in which the carrier operates. Thissystem typically has an interface to allow a user (e.g., a “DPS User”)to enter Alerts, Notes, and Procedures for various addresses,consignees, pickup accounts, and pickup events. The DPS allows the DPSUser to not only create, but also edit, review, and delete CPaD data.This information is compiled by the DPS into a DIAD Plan 702, whichcontains Alerts, Notes and Procedures associated with various addresses,consignees, pickup accounts, and/or pickup and delivery events asspecified by the DPS User in the DPS. In one embodiment, the DPS sendsthe DIAD Plan 712 to the DIAD Control System (DCS) 704 for transfer tothe DIAD 714.

Because the DPS 700 schedules the routes and dispatch plan for a givenvehicle, the DPS 700 has information for every pickup and deliveryscheduled for any vehicle in a particular service territory. Thus, anyCPaD data associated with a pickup or delivery can be communicated tothe DIAD associated with the pickup or delivery without involvement ofthe Preload Assist System (PAS) 710. However, as will be describedfurther below, CPaD data can be associated with a pickup or deliveryaddress, and the CPaD data may be sent to the DIAD via a differentroute. In this instance, the Preload Assist System (PAS) 710 receivespackages (Units of Work, or “UOWs”) and allocates them to a particulardelivery vehicle based on the preload plan 706 defined by the DPS 700.Typically, there are numerous delivery vehicles in a territory, and eachpackage coming into the carrier handling facilities must be routed tothe appropriate delivery vehicle for loading in a certain order. Thepreload plan 706 defines how the packages should be directed, and thePAS 710 uses the preload plan 706 to physically divert the packages tothe appropriate delivery vehicle for loading in the specified order.

The PAS 710 retrieves CPaD data from the CPaD Matrix File 708. Althoughnot shown, the DPS 700 and DCS 704 can also retrieve data from the CPaDMatrix File 708. The CPaD Matrix File 708 may comprise CPaD dataassociated with a consignee's address, a particular package, or otherdata. The file can be generated in a variety of ways, including dataentry by a customer service agent. The agent may receive CPaD datagenerated by a consignor using a consignor shipping system interfacingwith the carrier's systems. In other embodiments, the CPaD data may bereceived from consignees interacting with a carrier web site (e.g., inresponse to receiving notification of a delivery, as described above).In various other embodiments, the CPaD data may be CPPDI, provided bydelivery personnel or the carrier, as described above. The CPaD MatrixFile 708 can also comprise territory related information, procedurerelated data, general shipper related data, and specific shipper numberdata.

For each package loaded onto the delivery vehicle, the PAS 710 checks ifthere is any associated CPaD data in the CPaD Matrix File 708 andtransfers that information along with the Alerts, Notes, and Proceduresto the DIAD. The PAS 710 provides the CPaD data regarding the packagesloaded onto the delivery vehicle to the appropriate DIAD 714 using aRoute Manager (RM) 712 as a conduit. As described above, the DIAD 714also receives information regarding the packages from the DCS 704 thatprovides information about the route and the deliveries. Typically, theCPaD data is provided to the DIAD 714 using a wireline connection priorto the start of the day's deliveries, during which time package relatedinformation is downloaded into the DIAD. In some embodiments, CPaDinformation can be sent wirelessly to the DIAD after the deliveryvehicle has departed for the day's deliveries. The wireless transmissionof data can use any of the well known wireless data transfer mechanisms.

The CPaD Matrix File & Methods for Linking CPaD Data with Other Data

The CPaD Matrix File, described above, can contain various CPaD data aswell as other relevant data, such as shipping data. At a high level, a“delivery” can be represented as a record being stored in a databasehaving various fields. The database record for a “delivery” can beconceptually indexed or viewed as a collection of records based on anyvariety of fields, including the shipper (such as the consignor'sidentity, address, or unique consignor identification number), package(e.g., tracking number), consignee (e.g., consignee name, address, orunique consignee identification number), delivery truck route, etc.

Any particular data field associated with a delivery related record canbe thought of as shipment-dependent data, and is called herein a“delivery-related datum” (DRD). From an implementation aspect, CPaD data(which may be shipment-independent or shipment-dependent) can beassociated or linked with any DRD within the CPaD Matrix File. Forexample, every package delivery is associated with a consignee'saddress. Thus, the consignee's address is one example of a DRD which canbe linked to CPaD data. Each delivery is also associated with a shipper(consignor). Thus, the shipper is another form of a DRD, which can belinked to a particular piece of CPaD data. Another example of a DRD is apackage identifier such as a tracking number, which is an alpha-numericvalue many carriers assign to each package and/or delivery and typicallyused for tracking purposes. CPaD data can also be linked to a packagetracking number. Thus, CPaD data can be associated with any DRD, or aset of DRD associated with a delivery. Thus, CPPDI provided by thecarrier, or consignee and consignor personalized information can belinked to DRD for a particular package or delivery.

Various examples illustrate how CPaD data can be associated withdifferent DRD. As discussed above, consignee personalized deliveryinstructions or preferences can be provided for delivery of a specificpackage. Thus, the CPaD data (the personalized delivery instructions),would be linked with a DRD, which likely would be the package trackingnumber. By associating the personalized delivery instructions with thepackage tracking number, the relevant carrier systems are able toprovide the appropriate information to the DIAD at the proper time. Forexample, if the CPaD data contained an indication that delivery was tobe made to the back door at the consignee's address, by linking thisdata to the package tracking number, this information could be providedas a Note to the DIAD at the time when the delivery personnel deliversthe package to the consignee's address.

As another example, if the CPaD data is CPPDI, indicating that aparticular pickup location is closed for two weeks, this CPaD data couldbe linked with the relevant DRD, namely, the address of the pickuplocation (such as the consignor's address, for instance). By linkingthis data, the relevant carrier systems would know to trigger thisinformation to the DIAD at the beginning of the delivery day, so thatthe delivery personnel knows not to drive to this location.

As yet another example, consider a retail business that normallyschedules packages to be picked up every business day. The business mayrequest that a particular loading dock be used for all packagepickups/deliveries for a given time period week while the normal loadingdock is undergoing renovation. In this case, the information mayindicate that a certain loading dock should be used for a given timeperiod. It would be appropriate to associate this delivery preferenceinformation with the pickup/delivery address for a given time period.This would avoid having to link the CPaD data to each and every packagedelivered and/or picked up at that location.

Various possibilities for linking CPaD data to DRD are possible, and thefollowing list represents a few of the possibilities of how CPaD datacan be linked. For example, a delivery preference could be associatedwith: a consignee's address, an address with a specific consignee, anindividual consignee within that building, consignee's floor of amulti-story building, pickup location of a specific packaging beingdelivered, pickup location for a set of packages, shipper number, orpackage tracking number.

The linking or association of CPaD data to DRD is relevant because itcan impact how and when the CPaD data is displayed and/or loaded in theDIAD (e.g., the conditions in which the delivery personnel is made awareof the CPaD data) as well as how the delivery preference data may bestored by the carrier. For example, if the delivery preference is linkedwith a package tracking number, the delivery preference may be stored orlinked with a package level detail database record. If it is linked to aservice location, a separate database may be used for storing theinformation.

CONCLUSION

Many modifications and other embodiments of the inventions set forthherein will come to mind to one skilled in the art to which theseinventions pertain having the benefit of the teachings presented in theforegoing descriptions and the associated drawings. Therefore, it is tobe understood that the inventions are not to be limited to the specificembodiments disclosed and that modifications and other embodiments areintended to be included within the scope of the appended claims.Although specific terms are employed herein, they are used in a genericand descriptive sense only and not for purposes of limitation.

1. A method for providing information regarding at least one package tobe delivered to a customer, the method comprising: storing notificationpreferences for providing information to a customer regarding a packageto be delivered to the customer, wherein the notification preferencesidentify at least one communication format and at least onecorresponding electronic destination address to be used in providing theinformation to the customer; automatically generating a messageproviding the information regarding the package to be delivered to thecustomer; and automatically transmitting the message to the at least onecorresponding electronic destination address prior to the first deliveryattempt of the package to the customer.
 2. The method of claim 1,wherein the at least one communication format is selected from the groupconsisting of a text message, an email message, and a voice message. 3.The method of claim 1 further comprising receiving the notificationpreferences as input from the customer.
 4. The method of claim 1,wherein the notification preferences are stored in association with aprofile of the customer.
 5. A computing system for providing informationregarding at least one package to be delivered to a customer comprisingat least one processor and at least one memory, the computing systemconfigured to: store notification preferences for providing informationto a customer regarding a package to be delivered to the customer,wherein the notification preferences identify at least one communicationformat and at least one corresponding electronic destination address tobe used in providing the information to the customer; automaticallygenerate a message providing the information regarding the package to bedelivered to the customer; and automatically transmit the message to theat least one corresponding electronic destination address prior to thefirst delivery attempt of the package to the customer.
 6. The computingsystem of claim 5, wherein the at least one communication format isselected from the group consisting of a text message, an email message,and a voice message.
 7. The computing system of claim 5, wherein thecomputing system is further configured to receive the notificationpreferences as input from the customer.
 8. The computing system of claim5, wherein the notification preferences are stored in association with aprofile of the customer.